[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140723233832.GF11570@brightrain.aerifal.cx>
Date: Wed, 23 Jul 2014 19:38:32 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Locale bikeshed time
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.
> 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.
