From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5573 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Wed, 23 Jul 2014 19:38:32 -0400 Message-ID: <20140723233832.GF11570@brightrain.aerifal.cx> References: <20140722184932.GA4914@brightrain.aerifal.cx> <20140722201008.GC16795@example.net> <20140722203540.GA11570@brightrain.aerifal.cx> <20140723095031.GE16795@example.net> <20140723163907.GC11570@brightrain.aerifal.cx> <53D043C9.8020102@midipix.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406158733 17301 80.91.229.3 (23 Jul 2014 23:38:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Jul 2014 23:38:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5578-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 24 01:38:47 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XA67R-0005lR-NW for gllmg-musl@plane.gmane.org; Thu, 24 Jul 2014 01:38:45 +0200 Original-Received: (qmail 26384 invoked by uid 550); 23 Jul 2014 23:38:44 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26376 invoked from network); 23 Jul 2014 23:38:44 -0000 Content-Disposition: inline In-Reply-To: <53D043C9.8020102@midipix.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5573 Archived-At: On Wed, Jul 23, 2014 at 07:22:49PM -0400, writeonce@midipix.org wrote: > On 07/23/2014 12:39 PM, Rich Felker wrote: > >On that topic, while this is a matter outside my control for > >individual users, my preference would be that the official > >musl-locale data attempt to avoid multiple variants/modifiers and > >legacy options if possible. For example I would like to see the > >numeric date format be ISO format in all locales, with traditional > >formats only where the natural-language string representations for > >months/days are included (and I say this as someone coming from > >one of the locales, i.e. US, where the traditional numeric date > >format is non-ISO). In keeping with the principle that musl is > >"modern" I'd like to prefer modern cultural conventions to > >historical ones. > For what it's worth, I wanted to point out that the ISO C explicitly > pertains to the Gregorian calendar only, albeit in parenthesis > (N1570, 7.27.1). For users of [listed in alphabetical order:] > Arabic, Chinese, Hebrew, Japanese, Persian, and Tibetan, for > instance, there are two different issues at stake: the first is the > representation of the date according to the Gregorian calendar in > one's own language, which could (~easily~) be made "modern" (ISO > compliant), whereas the second is the representation of the date > according to the culture's native calendar in the language matching > the current locale. > > While I'm not necessary suggesting that musl (or any other libc, for > that matter) should implement the conversion functions from the > Gregorian calendar to other calendars and vice versa, it would be > nice if at least the prototypes of the conversion functions were > somehow standardized, and also if the locale files likewise > accounted for the above issues (e.g. in the form of placeholders). The strftime function has the %E? conversion specifiers which, if supported, could provide this kind of functionality, I think. I have no idea how to represent the rules for the conversions, though, or whether doing so would be practical. > PS. speaking of historical vs. modern and LC_MONETARY, we should > probably bear in mind the many locale variants that are based on > currency only, as for example in the case of EU member countries > before and after the Euro. Interesting point I hadn't really thought of. Rich