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/18666] Add support for '%OY' in strftime(), currently only "%Oy" is supported


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

TAMUKI Shoichi <tamuki at linet dot gr.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tamuki at linet dot gr.jp

--- Comment #3 from TAMUKI Shoichi <tamuki at linet dot gr.jp> ---
Created attachment 11755
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11755&action=edit
The results of running tst-strftime2 (experimental)

I am working on a feature that enables alternative representation for
year with alternative numeric symbols in glibc (Bug 24453).  As the
next step, it is important to solve the issue here for some specific
locales.

In lzh_TW locale, it is Minguo year 108 and has reached three digits.
This cannot be constructed with the characters currently present in
the locale data.

We also have the same issue in the dominical year representation.
When representing year in Chinese numeric symbols in Japan, it is
common to use the content of alt_digit array as it is if it is less
than 100, and to concatenate '0' to '9' if it is greater than or equal
to 100.  According to the developer who is a Chinese (Taiwan) native
speaker, when representing year in Chinese numeric symbols in Taiwan,
it is common to use as follows, as in Japan (Bug 24471):

        ja_JP           lzh_TW
0       〇              〇
1       一              一
2       二              二
3       三              三
4       四              四
5       五              五
6       六              六
7       七              七
8       八              八
9       九              九
10      十              十
11      十一            十一
[...]
31      三十一          卅一
[...]
99      九十九          九十九
100     一〇〇          一〇〇
[...]
108     一〇八          一〇八
[...]
645     六四五          六四五
[...]
2019    二〇一九        二〇一九

This scheme will also work well for or_IN locale that uses alt_digits.
On the other hand, for fa_IR, az_IR, my_MM, and shn_MM locales, which
have zero paddings in alt_digits themselves, they may need to be
fixed.

I attached the results of running tst-strftime2 (experimental).

-- 
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]