From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5575 Path: news.gmane.org!not-for-mail From: "writeonce@midipix.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Locale bikeshed time Date: Wed, 23 Jul 2014 21:07:22 -0400 Message-ID: <53D05C4A.5070307@midipix.org> 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> <20140723233832.GF11570@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406164065 9036 80.91.229.3 (24 Jul 2014 01:07:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2014 01:07:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5580-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 24 03:07:38 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 1XA7VS-0000HQ-Fl for gllmg-musl@plane.gmane.org; Thu, 24 Jul 2014 03:07:38 +0200 Original-Received: (qmail 1617 invoked by uid 550); 24 Jul 2014 01:07:37 -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 1608 invoked from network); 24 Jul 2014 01:07:37 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 In-Reply-To: <20140723233832.GF11570@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:5575 Archived-At: On 07/23/2014 07:38 PM, Rich Felker wrote: > 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. The conversion function I'm missing is one that would produce a native struct tm from either a "general" (Gregorian), or a UTC struct tm. Consider for instance the case of lunisolar calendars with an occasional thirteenth month (i.e. Hebrew, Tibetan): given a Gregorian date, it is often useful to store the corresponding native date in a struct tm, manipulate it in some way (for instance finding the number of days left until the end of the native month), and then print the result. There are already a lot of applications and websites that perform such calculations, yet no standard interface for the conversion functions (at least not as far as I can tell). In terms of practicality: for many of the calendars I mentioned, conversion involves not only a formula, but also date- and year-based considerations. A correct implementation of all the %E? specifiers is accordingly going to include many bytes of code that probably shouldn't be pulled in whenever a "random" static application uses strftime. That being said, if musl's implementation of %E? could use weak aliases and standardized hooks, then applications or calendar-specific libraries could provide these hooks and still use the libc strftime, rather than a complex system of wrappers and conditionals. * Not be extra difficult or anything, but even the simple example in N1570 ("what day of the week is July 4, 2001") contains a cultural bias, namely the assumption that days begin and end at midnight;-) zg > >> 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 > >