Bug 1145730 - date format not set for en_IN
Summary: date format not set for en_IN
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Mike FABIAN
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-23 14:57 UTC by Arjun Shankar
Modified: 2019-05-21 06:01 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-21 06:01:49 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Sourceware 17426 None None None 2019-05-21 05:51:51 UTC

Description Arjun Shankar 2014-09-23 14:57:57 UTC
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).

Comment 1 Jaroslav Reznik 2015-03-03 16:19:16 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

Comment 2 Fedora End Of Life 2016-07-19 20:06:50 UTC
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.

Comment 3 Pravin Satpute 2017-07-05 07:57:18 UTC
(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.

Comment 4 Florian Weimer 2017-07-05 08:11:22 UTC
(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.

Comment 5 Pravin Satpute 2017-07-05 09:36:34 UTC
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 :)

Comment 6 Florian Weimer 2017-07-05 09:41:06 UTC
(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.

Comment 7 Debarshi Ray 2017-07-19 09:31:08 UTC
(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

Comment 8 Jan Kurik 2017-08-15 06:53:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 9 Mike FABIAN 2018-11-20 06:24:59 UTC
Fixed  upstream.

Comment 10 Mike FABIAN 2019-05-21 06:01:18 UTC
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:~
$


Note You need to log in before you can comment on or make changes to this bug.