Bug 1145730
| Summary: | date format not set for en_IN | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Arjun Shankar <ashankar> |
| Component: | glibc | Assignee: | Mike FABIAN <mfabian> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | aalam, codonell, debarshir, fweimer, i18n-bugs, jakub, law, mfabian, mnewsome, pfrankli, pnemade, pranav913, psatpute |
| Target Milestone: | --- | Keywords: | i18n, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-05-21 06:01:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Arjun Shankar
2014-09-23 14:57:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. (In reply to Arjun Shankar from comment #0) > Already filed upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=17426 > > executing: > $ LC_TIME=en_IN.UTF-8 date +%x > > prints: > Tuesday 23 September 2014 > > This isn't the format used in India. > > I have typically seen DD-MM-YY(YY) or DD/MM/YY(YY) in use in most places > including official tax forms, etc. > > Here is the link to a copy of the Constitution of India: > http://india.gov.in/my-government/constitution-india/constitution-india-full- > text > > It appears to consistently use "DD-MM-YYYY" (when I looked at the main > "Parts I to XXII" document). Hi Arjun, Thanks for this bug report. As a platform we follow standards, i.e. Unicode, Unicode CLDR and government standards for language related issues. Do you any specific reference for this change from such standard? I hope, you understand Constitution of India is not ideal reference for this change. (In reply to Pravin Satpute from comment #3) > Do you any specific reference for this change from such standard? > > I hope, you understand Constitution of India is not ideal reference for > this change. Most national standardization bodies have formally adopted the ISO 8601 standard, but that doesn't mean that this format is actually used and people expect it to see (which is what glibc locales should match). I think standards are poor guideline for locale changes (at least in the date/time space), especially if we can talk to users and have plenty of usage examples on the web. Does this mean, we will have multiple locales? i.e. One locale following ISO 8601 and other following what is in used. With my experience of maintaining default fonts in system, i always preferred to follow standards, since it easy to get things sorted out at standardization body level but its difficult to get consensus on bugzilla. Just my few cents :) (In reply to Pravin Satpute from comment #5) > Does this mean, we will have multiple locales? i.e. One locale following > ISO 8601 and other following what is in used. No, I think two locales with ISO 8601 would suffice (one with ' ' between date and time, one with 'T' for full compliance). They could be combined with other locales using LC_TIME. > With my experience of maintaining default fonts in system, i always > preferred to follow standards, since it easy to get things sorted out at > standardization body level but its difficult to get consensus on bugzilla. > Just my few cents :) We don't have to reach complete agreement. (In reply to Pravin Satpute from comment #3) > Thanks for this bug report. As a platform we follow standards, i.e. > Unicode, Unicode CLDR and government standards for language related issues. > > Do you any specific reference for this change from such standard? > > I hope, you understand Constitution of India is not ideal reference for > this change. He already provided further references, including an extract from the Unicode CLDR, in the upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17426 This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'. Fixed upstream. Fixed in Fedora 30: mfabian@taka:~ $ LC_TIME=en_IN.UTF-8 date +%x 21/05/19 mfabian@taka:~ $ rpm -q glibc glibc-2.29-12.fc30.x86_64 mfabian@taka:~ $ cat /etc/fedora-release Fedora release 30 (Thirty) mfabian@taka:~ $ |