Bug 18666

Summary: Add support for '%OY' in strftime(), currently only "%Oy" is supported
Product: glibc Reporter: Sandeep Shedmake <sandeep.shedmake>
Component: timeAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: digitalfreak, drepper.fsp, ppluzhnikov, tamuki
Priority: P2 Flags: fweimer: security-
Version: 2.21   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: screenshot showing '%OY' instead of 4 digit year with evolution-3.16.3-2.fc22 for or_IN locale
The results of running tst-strftime2 (experimental)

Description Sandeep Shedmake 2015-07-14 09:11:58 UTC
Created attachment 8435 [details]
screenshot showing '%OY' instead of 4 digit year with evolution-3.16.3-2.fc22 for or_IN locale

Description of problem:
Add support for '%OY' in strftime(). Currently it doesn't support "%OY", only "%Oy" is supported and thus 4-digit year is not possible.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. $ LANG=or_IN.utf8
2. $ date +%Om-%Od-%OY

Actual results:
୭-୧୩-%OY (4 digit year not supported)

Expected results:
୭-୧୩-%OY (4 digit year should be supported: ୭-୧୩-୨୦୧୫)

Additional info:
$ LANG=or_IN.utf8 date +%Om-%Od-%Oy
Comment 1 Paul Pluzhnikov 2015-08-15 19:35:51 UTC
AFAICT the newest Single UNIX strftime spec http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html explicitly mentions '%Oy' (and '%EY'), but not '%OY'.

Looks like a possible standard defect.
Comment 2 Rafal Luzynski 2017-12-22 00:43:39 UTC
I don't mind adding a support of "%OY". But the root reason is that alt_digits array in nl_langinfo() can contain only up to 100 elements. Are we able to construct a 4-digit number like 2017 using these characters? Currently only 7 locales use alt_digits: az_IR, fa_IR, ja_JP, lzh_TW, my_MM, or_IN, shn_MM. (Please ignore uk_UA, it will be removed very soon.) Can we safely assume these alternative systems are decimal? It seems that yes. Can we safely assume that "2017" is a concatenation of "2" + "0" + "1" + "7"? Seems like it's true for om_IN but false for fa_IR. Because om_IN contains digits like "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11",… while fa_IR contains digits like "00", "01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11",… What about "20" + "17"? Seems like it's true for both om_IN and fa_IR. What about 2007, is it "20" + "07" or rather "20" + "7"? Seems like it's correct in fa_IR but not om_IN.

ja_JP and lzh_TW seem to be even more cryptic to me, it looks like they have separate symbols for "10", "20", "30" etc. which are not combinations of "1" + "0", "2" + "0" etc. I'm afraid that the numbers like "2000" or "1990" cannot be constructed with the characters currently present in their locale data.

So before we start supporting %OY we must define what is the content of alt_digits array (should a leading zero precede the numbers from 0 to 9 or not) and how to handle the systems which have more than 10 digits, like (probably) ja_JP and lzh_TW.
Comment 3 TAMUKI Shoichi 2019-04-29 04:56:31 UTC
Created attachment 11755 [details]
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

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

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