This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug time/18666] Add support for '%OY' in strftime(), currently only "%Oy" is supported
- From: "tamuki at linet dot gr.jp" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 29 Apr 2019 04:56:31 +0000
- Subject: [Bug time/18666] Add support for '%OY' in strftime(), currently only "%Oy" is supported
- Auto-submitted: auto-generated
- References: <bug-18666-131@http.sourceware.org/bugzilla/>
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.