| Summary: | Add support for '%OY' in strftime(), currently only "%Oy" is supported | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Sandeep Shedmake <sandeep.shedmake> |
| Component: | time | Assignee: | 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) |
||
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. 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. 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 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). |
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): glibc-2.21-5.fc22.x86_64 How reproducible: Always 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 ୭-୧୩-୧୫