From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 635B63858013; Thu, 6 Jan 2022 22:03:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 635B63858013 From: "carlos at redhat dot com" To: libc-locales@sourceware.org Subject: [Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME Date: Thu, 06 Jan 2022 22:03:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: libc-locales at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: see_also 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-BeenThere: libc-locales@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-locales mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2022 22:03:51 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D4628 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.mozilla.or | |g/show_bug.cgi?id=3D1509096 --- Comment #22 from Carlos O'Donell --- (In reply to David Woodhouse from comment #21) > Any progress on this? I am not aware of any progress on this issue. Let me summarize the current state over the 14+ years this bug has been ope= n. I feel that ISO 8601 is a red-herring here, and the vast majority of users = are simply talking about d_fmt and the default becoming YYYY-MM-DD for their particular use case. There are three positions that can be taken on default value of d_fmt: (a) A locale represents the information for an application to use to present such information to someone local in that locale. Thus d_fmt should be used when exchanging information locally (whatever that means). An application m= ay make a choice that in the context of the application's use of the data choo= se to present the data in a more interoperable unambiguous format, a 21st cent= ury way, e.g. YYYY-MM-DD for d_fmt. (b) A locale represents the default way information should be presented, an= d in the 21st century, this means d_fmt should be YYYY-MM-DD. (c) The framework should allow for easy customization of the pattern used f= or d_fmt, without loosing the language-specific localization in the rest of LC_TIME. Several early responders to this issue in 2007 took the position of (a), and that no further work was required in glibc. Users were rightly upset because the solution of making your own locale is not well supported by glibc as a process in general. Also users only really wanted d_fmt to be YYYY-MM-DD, a= nd everything else the same. Some users over time have taken the position (b). Recent glibc developers have started to come around to (c), and it follows = on from the fact that ICU and other libraries do allow a certain amount of dyn= amic customization of date format patterns, as seen in the solution for Thunderb= ird here:=20 "Implement pref overrides for date and time formats: intl.date_time.pattern_override.date_* and intl.date_time.pattern_override.time_* (was: TB 60 on Linux: Setting date locale to LC_TIME=3Den_DK.utf8 no longer outputs yyyy-MM-dd format)" https://bugzilla.mozilla.org/show_bug.cgi?id=3D1426907 To date we have several suggestions for a way forward: (1) Add @ variants to all locales. - Duplicate all locales, rename, and change d_fmt to %Y-%m-%d (with clever include usage to reduce duplication). (2) Add @ variants to a few key locales. - Solution (1) but reduce the overall work and gives some users a solutions. (3) Implement a language:territory layering. - Provide a new format for specifying LC_TIME that allows a user to layer language and territory information. LC_TIME would need to be split into language-specific entries, and territory-specific entries (language neutral= ), and allow layering. None of (1), (2) or (3) have been implemented to date. I see maybe another way forward: (4) New pattern with override selection. Following the Mozilla and ECMA Script recommendations it might be more poss= ible to define variants of d_fmt, and allow users to pick a variant e.g. In environment: LC_TIME=3Den_US,d_fmt=3D{iso8601} In locale sources: d_fmt "%m//%d//%Y" % Variant {iso8601} pattern for d_fmt. d_fmt_iso8601 "%Y-%M-%d" Where the locale sources provide tested canonical patterns for the variants. Then users can pick the variants and we can easily add variants. At the implementation level we would need to change a pointer after parsing the env var and we would also break the sharing of some of the pages of the mmap'd binary locale. Notes: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1426907 https://bugzilla.mozilla.org/show_bug.cgi?id=3D1509096 https://unicode-org.atlassian.net/browse/CLDR-5769 https://unicode-org.atlassian.net/browse/CLDR-12027 https://github.com/tc39/proposal-intl-datetime-style --=20 You are receiving this mail because: You are the assignee for the bug.=