From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108943 invoked by alias); 30 Aug 2018 10:55:53 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 108835 invoked by uid 48); 30 Aug 2018 10:55:49 -0000 From: "digitalfreak at lingonborough dot com" To: libc-locales@sourceware.org Subject: [Bug localedata/17426] Indian locales: set the correct date format Date: Thu, 30 Aug 2018 10:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: 2.20 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: digitalfreak at lingonborough dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2018-q3/txt/msg00073.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17426 Rafal Luzynski changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|en_IN: set date format |Indian locales: set the | |correct date format --- Comment #9 from Rafal Luzynski = --- This needs further work so I change the bug summary. Statistics =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Glibc currently supports 34 Indian locales (see the incomplete list in comm= ent 7). Only 19 of them are also supported by CLDR. For others we must figure= out the correct date format based on other similar locales. There is one locale (bo_IN) which uses "copy..." for LC_TIME instead of providing its own content and one locale (ccp_IN) which is supported by CLDR but not by glibc. I will ignore those two. Current state =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The most popular value of d_fmt in Indian locales is "%A %d %b %Y". It is provided by 25 locales: anp_IN, bhb_IN, bho_IN, bn_IN, brx_IN, doi_IN, gu_I= N, hi_IN, hne_IN, kn_IN, kok_IN, ks_IN, ks_IN@devanagari, mag_IN, mai_IN, mni_= IN, mr_IN, pa_IN, raj_IN, sa_IN, sat_IN, sd_IN, sd_IN@devanagari, tcy_IN, ur_IN. The second most popular is "%A %d %B %Y". Supported by 4 locales: ar_IN, mjw_IN, ml_IN, ta_IN. It has also been supported by the 5th locale: en_IN = but it has been changed to "%d/%m/%y" just days ago. Most probably your comput= ers still provide the old date format for en_IN. as_IN uses "%e-%m-%Y". or_IN uses "%Od-%Om-%Oy". It seems to me that someone made an effort to ad= apt the locale to the actual needs of the local community. I will not touch th= is. te_IN uses "%B %d %A %Y". This looks like a typo (Month dd Weekday yyyy) a= nd I'm pretty sure someone actually meant "%A %d %B %Y". Proposed changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For those locales which currently use "%A %d %b %Y" or "%A %d %B %Y" CLDR provides "d/M/yy" (day number, as many digits as required - not padded, not truncated; month number, as many digits as required; year number, truncated= to 2 digits). Glibc equivalent is: "%-d/%-m/%y". Locales: bn_IN, gu_IN, hi_IN, kn_IN, ml_IN, mr_IN, pa_IN, ta_IN, ur_IN. (9 locales) Consequently I think that these locales which are not supported by CLDR but currently provide the same value of d_fmt should accept the same change: anp_IN, ar_IN, bhb_IN, bho_IN, doi_IN, hne_IN, mag_IN, mai_IN, mjw_IN, mni_= IN, raj_IN, sat_IN, sd_IN, sd_IN@devanagari, tcy_IN. (15 locales) However, it may be disputable if actual Indian users want the month number = to be zero-padded or not. That means, should today date be formatted as "30/8= /18" and Sept 1st as "1/9/18" or maybe rather "30/08/18" and "1/09/18" or even "30/08/18" and "01/09/18". Note that ur_IN is in this group and ur_PK currently provides "%d/%m/%Y" ("30/08/2018" and "01/09/2018"). For as_IN CLDR suggests "d-M-y" which should translate to "%-d-%-m-%y" or "%-e-%-m-%y". Current value is "%e-%m-%Y" (zero padded month number, 4 dig= its year). Maybe leave unchanged? For brx_IN and ks_IN which use "%A %d %b %Y" CLDR provides "M/d/yy" which translates to "%-m/%-d/%y". Consequently I think that ks_IN@devanagari whi= ch is not supported by CLDR should have the same value. (3 locales) For kok_IN which currently uses "%A %d %b %Y" CLDR provides "d-M-yy" which translates to "%-d-%-m-%y". For sa_IN which currently uses "%A %d %b %Y" CLDR provides "d-MM-yy" which translates to "%-d-%m-%y". (Difference: in sa_IN month number should be zero-padded to 2 digits, in kok_IN should not). For te_IN which currently uses "%B %d %A %Y" (a typo IMHO) CLDR provides "dd-MM-yy" which translates to "%d-%m-%y". en_IN has been already updated. Thoughts? --=20 You are receiving this mail because: You are on the CC list for the bug.