Re: glibc 2.29 - Winter is coming...

[Rafal Luzynski <digitalfreak at lingonborough dot com>]

2.01.2019 19:24 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> 
> On 02/01/19 5:22 PM, Rafal Luzynski wrote:
> > [...]
> > [1] Cyrillic -> ASCII transliteration: I am not sure which locale should
> [...]
> However, I am acutely aware that I may not understand the gravity of 
> some of the differences and you're free to throw my opinions out the 
> window :)

Thank you, I will reply in the proper thread.

> > [2] [3] Default width for "%Ey" which is important due to the Japanese
> > era change in 4 months.  Also, this patch fixes handling of formatting
> > flags so if that helps it can be split into the patches fixing the width
> > issue and fixing the flags issue.
> 
> A more detailed explanation of what the Japanese era change entails is 
> needed in here, i.e. why is the padding needed

Each Japanese era year is the year of reign of the current emperor.
The current year is 31 (2 digits).  As soon as the new era is announced,
the new year will have the number 1 (one digit).  As far as I understood,
they do not want the year to be formatted as "1" but "01" instead because
they want to keep the constant width output for example in logs.
My reasoning is that "%y" is always zero-padded to 2 digits so for the
consistency let's set "%Ey" to be zero-padded to 2 digits as well.

The new Japanese era is already scheduled. [1]

> and what would the output 
> look like if we don't fix it in this release and why that would be a 
> problem.

For the comparison, here is the output of the current year and 1990 which
had the same problem:

$ LC_ALL=ja_JP.utf8 date +%Y
2019
$ LC_ALL=ja_JP.utf8 date +%EY
平成31年
$ LC_ALL=ja_JP.utf8 date +%Y -d "29 years ago"
1990
$ LC_ALL=ja_JP.utf8 date +%EY -d "29 years ago"
平成2年

I think they want: "平成02年".

An explanation why I use here "%Y" and "%EY" while we are talking
about "%Ey".  The reason is that "%EY" is expanded into a subformat which
may contain "%Ey" as the actual year number.

> Other than that, this seems like something we can make an exception for, 
> assuming that it does not affect translations.

It does not affect translations of glibc but does affect translations of
applications to a minor extent: the zero-padded output is one character
wider than the non-zero-padded one.  But:

* this is exactly what they want,
* the output for the current year (and 21 previous years) is already the
same wide as a zero-padded single digit year.

> I personally would have 
> done 2 different patches, but I know others in the community who would 
> have stuck this into a single patch so I don't have too strong an 
> opinion about that aspect of this patch.

The other issue is that the additional flags like "%-EY" or "%_EY" are
ignored.  I was going to say that this is not related with the era
change but actually it is: as long as the year number had 2 digits
those flags were correctly ignored.  Now the users will have a good
reason to expect them to work correctly.

Regards,

Rafal

[1] https://en.wikipedia.org/wiki/2019_Japanese_imperial_transition