Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Jul 2014 21:07:22 -0400
From: "" <>
Subject: Re: Locale bikeshed time

On 07/23/2014 07:38 PM, Rich Felker wrote:
> On Wed, Jul 23, 2014 at 07:22:49PM -0400, 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;-)


>> 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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.