[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53D05C4A.5070307@midipix.org>
Date: Wed, 23 Jul 2014 21:07:22 -0400
From: "writeonce@...ipix.org" <writeonce@...ipix.org>
To: musl@...ts.openwall.com
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, writeonce@...ipix.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
>
>
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.
