This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug time/23758] New: Improve the width of alternate representation for year in strftime


https://sourceware.org/bugzilla/show_bug.cgi?id=23758

            Bug ID: 23758
           Summary: Improve the width of alternate representation for year
                    in strftime
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: tamuki at linet dot gr.jp
  Target Milestone: ---

The Japanese era name is scheduled to be changed on May 1, 2019.
Prior to this, improve the width of alternate representation for year
in strftime to prevent the trouble to be mentioned below we saw in the
past from becoming obvious again from the year after the era name
changes onward.

At present, in one-digit of the Japanese era year such as Heisei year
2 (1990), the conversion specifiers %Ex, %Ec to be included in the
format specification of strftime, are converted as follows.  However,
since the width of alternate representation for year of the output
string is different from the others, there was a sense of
incompatibility.

    "%Ex"       : "平成2年08月04日"
    "%Ec"       : "平成2年08月04日 08時06分02秒"

These conversion specifiers are implemented by combining multiple
conversion specifiers.  In ja_JP locale for example, the combinations
of conversion specifiers are defined as follows.

    "%Ex"       : "%EY%m月%d日" (era_d_fmt)
    "%Ec"       : "%EY%m月%d日 %H時%M分%S秒" (era_d_t_fmt)

    "%EY"       : "%EC元年" | "%EC%Ey年" (era_format)
    "%EC"       : "平成" | "昭和" | "大正" | "明治" (era_name)

Currently, the width of the output string of the numeric value of
conversion specifier %Ey is not padded.  By changing the width padding
with zero to 2, the conversion specifier %EY is converted as follows,
and then expected results are also obtained for conversion specifiers
%Ex, %Ec.

    "%EY"       : "平成2年" -> "平成02年"

    "%Ex"       : "平成02年08月04日"
    "%Ec"       : "平成02年08月04日 08時06分02秒"

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.  In addition, the width of month, day, hour, minute, and
second is 2, so adjust the width of year the same as them, the whole
display balance is improved.  Therefore, it would be reasonable to
change the width padding with zero of %Ey default to 2.

In glibc, besides ja_JP locale, the locales currently using the
conversion specifier above are lo_LA (Laos) and th_TH (Thailand).  In
these locales, they use the Buddhist era.  The Buddhist era is a value
obtained by adding 543 to the Christian era, so it is not affected by
this change of the conversion specifier %Ey.

Furthermore, for the output string of the conversion specifier %EY,
an optional flag is given to the conversion specifier so that it can
be also used the current non-padding format, and the padding format
can be controlled.  To achieve this, when an optional flag is given to
the conversion specifier %EY, processing is performed as the flag to
be given to %Ey included in the combined conversion specifier.

    "%EY"       : "%EC%Ey年"     : "平成02年"
    "%_EY"      : "%EC%_Ey年"    : "平成 2年"
    "%-EY"      : "%EC%-Ey年"    : "平成2年"

As an application example, by combining conversion specifiers, it can
be converted into the following display format.

    "%Ex(%a) %X"                        : "平成02年08月04日(土) 08時06分02秒"
    "%_EY%b%e日(%a) %_H時%_M分%_S秒"        : "平成 2年 8月 4日(土)  8時 6分 2秒"
    "%-EY%B%-d日(%a) %-H時%-M分%-S秒"       : "平成2年8月4日(土) 8時6分2秒"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]