Bug 18666 - Add support for '%OY' in strftime(), currently only "%Oy" is supported
Summary: Add support for '%OY' in strftime(), currently only "%Oy" is supported
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: time (show other bugs)
Version: 2.21
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2015-07-14 09:11 UTC by Sandeep Shedmake
Modified: 2017-12-22 00:43 UTC (History)
3 users (show)

See Also:
Last reconfirmed:
fweimer: security-

screenshot showing '%OY' instead of 4 digit year with evolution-3.16.3-2.fc22 for or_IN locale (52.35 KB, image/png)
2015-07-14 09:11 UTC, Sandeep Shedmake

Note You need to log in before you can comment on or make changes to this bug.
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.