Re: [PATCH] Improve the width of alternate representation for year in strftime [BZ #23758]

[TAMUKI Shoichi <tamuki at linet dot gr dot jp>]

Hello Paul,

Thank you for your review.

From: Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: [PATCH v2] Improve the width of alternate representation for year in strftime [BZ #23758]
Date: Sun, 28 Oct 2018 14:06:46 -0700

> TAMUKI Shoichi wrote:
> > Since only one Japanese era name is used by each emperor's reign, it
> > is rare that the year ends in one digit or lasts more than three
> > digits.
> 
> Rare recently, but over the long term about 75% of Japanese imperial
> years have been single-digit years: since 701 AD there have been 989
> single-digit years but only 329 two-digit years.  (This calculation is
> approximate, but it's close enough; see attached shell script for how
> I did the calculation.)  Although Japan is more stable now than it was
> centuries ago, the long reigns since 1868 are a historical aberration
> and it should not be surprising if the fraction of single-digit years
> reverts closer to historical levels in the not-too-distant future.

As you mentioned, before the Meiji era (1868), there were many eras of
short years.  However, since they used the Lunisolar calendar instead
of the Gregorian calendar before the Meiji era, it is difficult to
accurately represent dates in the current glibc scheme and I think
that we do not have to care from a practical point of view.  In fact,
before the Meiji era, there are not any era entries but defined AD and
BC instead in the Japanese locale data in glibc.  Also, it is
interesting to speculate that era years in future might be shorter
like before.  However, it does not necessarily guarantee that all eras
will be a single-digit year.  I think that it is reasonable to change
the width padding with zero of %Ey default to 2 so as to keep it a
constant width across the past and the future.

Regarding the commit message, I will change the expression as follows.

| Since only one Japanese era name is recently used by each emperor's
| reign, it is rare that the year ends in one digit or lasts more than
| three digits.

> Although I'm no expert in Japanese, as I understand it the most common
> style for formatting imperial dates in plain text uses no spaces
> anywhere,

The most common style for formatting the Japanese calendar dates in
plain text is not necessarily without spaces.

> It's far less common to see spaces to make things line up, presumably
> for tables.

I think these are the ones that will be used properly according to the
application.  Both the regular representation (%c, %x, %X) and the
alternate representation (%Ec, %Ex, %EX) in the Japanese locale of
glibc are defaulting to padded with zeros.  This is suitable for
expressing width sensitive, such as business forms.  Next, padding
with space is easy to read by humans while expressing them in the same
width, but on the other hand, it is not suitable for splitting fields
with delimiters of spaces.  Finally, a format that does not use
padding is suitable for inputs of applications that create output
equivalent to typesetting such as TeX.

> Since glibc is already defaulting to space padding for month and day-
> of-month, it makes sense for glibc to also default to space padding
> for imperial year.  However, this change should be announced more
> clearly.  The ChangeLog entry should say what's going on at a high
> level, and give an example call to strftime with the before-and-after
> output, along with how to generate imperial dates with no spaces; and
> (more important) the glibc documentation should for strftime should
> contain similar examples.

As mentioned above, in the Japanese locale of glibc are defaulting to
padded with zeros, so it is also natural to pad with a zero year in
the Japanese calendar.  In strftime of glibc document, it says as
follows.

| The default action is to pad the number with zeros to keep it a
| constant width.

The change from zero to space padding may cause backward compatibility
in the Japanese locale, so I think that it is OK as it is.

Since the change of this time makes sane handling of display width of
one-digit year for the Japanese calendar which was not encountered
directly so far since the Japanese locale of glibc appeared, I think
for now that it is unnecessary to add new document about the issue
specialized for the Japanese locale.

Regards,
TAMUKI Shoichi