From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5BD013858017; Fri, 7 Jan 2022 10:58:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5BD013858017 From: "dwmw2 at infradead dot org" To: libc-locales@sourceware.org Subject: [Bug localedata/4628] Provide rump locales with ISO 8601 variants for use with LC_TIME Date: Fri, 07 Jan 2022 10:58:07 +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: dwmw2 at infradead dot org 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: 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: Fri, 07 Jan 2022 10:58:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D4628 --- Comment #24 from David Woodhouse --- Thanks, Carlos. (In reply to Carlos O'Donell from comment #22)=20 > 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 th= eir > particular use case. Agreed. > There are three positions that can be taken on default value of d_fmt: It seems to me that these positions are retroactively (re)defining the very semantics of d_fmt, and the purposes for which e.g. strftime("%x") should be used. Yet applications have been using it in its current form for decades, = and it has been received wisdom that "well-behaved" applications will use the locale format for the date. We can change precisely what date format the applications get when they use= =20 d_fmt =E2=80=94 that is precisely the *point* of it, after all. But I'd sug= gest that it doesn't make much sense to talk about when/whether applications should use = it at all. That ship has sailed. > (a) A locale represents the information for an application to use to pres= ent > such information to someone local in that locale. Thus d_fmt should be us= ed > when exchanging information locally (whatever that means). An application > may make a choice that in the context of the application's use of the data > choose to present the data in a more interoperable unambiguous format, a > 21st century way, e.g. YYYY-MM-DD for d_fmt. It took me a while to parse the difference between (a) and (b) here, and the distinction between "for local only viewing" in (a) vs. "default" in (b). I think the final sentence of (a) should say that an application may explic= itly use e.g. YYYY-MM-DD (%Y-%m-%d) *instead* of using d_fmt (%x). Of course, in today's interconnected world the only application that can kn= ow its output will only be consumed locally is Snapchat. Anything that outputs text which can be shared via email/screenshots/files/databases would need to eschew the legacy d_fmt and explicitly use %Y-%m-%d instead. On top of which, even if an application *could* know that it's displaying o= nly to a local user, the archaic dd/mm/yy form of en_GB is *still* the wrong th= ing to display. The world has changed, with computers now being considered "bro= ken" if they cannot instantly communicate with others on a different continent, = and the legacy dd/mm form is a poor choice even for *local* communication becau= se users are inundated with dates in 'wrong' mm/dd form that makes it ambiguou= s. Applications should just use %Y-%m-%d everywhere, unconditionally. So if we choose (a) then we should change the strftime(3) man page to make = it clear that the %x format is deprecated and should never be used, much like = the warning we already have on %D. And we should patch all the applications in = the world, something like this... - strftime(buf, sizeof(buf), _("The date is %x"), tm); + strftime(buf, sizeof(buf), _("The date is %Y-%m-%d", tm); > (b) A locale represents the default way information should be presented, = and > in the 21st century, this means d_fmt should be YYYY-MM-DD. This is my understanding of the current position. Well-behaved applications *should* use d_fmt, and it *should* do something appropriate based on which country, and which millennium, the user is living in. Instead of deprecating '%x' and declaring that decent applications will cha= nge to manually use %Y-%m-%d, which is the logical conclusion of choice (a), ch= oice (b) would simply use the existing flexibility to make existing applications= do the right thing seamlessly. It seems like the better choice to me. > (c) The framework should allow for easy customization of the pattern used > for d_fmt, without loosing the language-specific localization in the rest= of > LC_TIME. I don't even know that this needs to be selectable at run time. A build time choice could be perfectly sufficient, wouldn't it? Let's switch viewpoints and look at the user/application experience rather = than the implementation side. Let's also take a slightly less contentious example which really is just a = bug. Poland *officially* adopted the YYYY-MM-DD format in 2002, yet 'LC_TIME=3Dp= l_PL date +%x' still seems to output the legacy 07.01.2022 format. Shouldn't that one just be fixed in the next glibc release? Should we file a separate bug = for it? A *distribution* might then want to revert that change, perhaps if shipping= the new glibc as an update to an existing system (to avoid breaking some admittedly-already-broken screenscraping scripts). So making it a build-time option would be useful. But the next major release of the distribution would probably just use the "new" post-2002 d_fmt for pl_PL. For the individual user, the experience would just be that in a new version, the behaviour gets updated. And if they *really* object to the fixed behavi= our, they still have the (runtime) option of building their own locale to regres= s it for themselves. It's not trivial, but it doesn't *need* to be. And if we can do it for pl_PL (which we absolutely should), then why should= n't we do the same for *all* locales? Because this far into the 21st century, %Y-%m-%d is the only sane way to represent numeric dates. > I see maybe another way forward: >=20 > (4) New pattern with override selection. >=20 > Following the Mozilla and ECMA Script recommendations it might be more > possible to define variants of d_fmt, and allow users to pick a variant e= .g. >=20 > In environment: > LC_TIME=3Den_US,d_fmt=3D{iso8601} >=20 > In locale sources: > d_fmt "%m//%d//%Y" > % Variant {iso8601} pattern for d_fmt. > d_fmt_iso8601 "%Y-%M-%d" If you do proceed with runtime options, please ensure that the *default* is YYYY-MM-DD and that the suffix is required to go back to the legacy form. Or define *both* 'iso8601' and 'legacy' suffixes and allow the system default = to be configured at build time (and *that* should default to iso8601). --=20 You are receiving this mail because: You are the assignee for the bug.=