[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53D06C88.2010506@midipix.org>
Date: Wed, 23 Jul 2014 22:16:40 -0400
From: "writeonce@...ipix.org" <writeonce@...ipix.org>
To: musl@...ts.openwall.com
Subject: Re: Locale bikeshed time
On 07/23/2014 09:57 PM, Rich Felker wrote:
> On Wed, Jul 23, 2014 at 09:07:22PM -0400, writeonce@...ipix.org wrote:
>> 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
> Obviously unless the set of such rules is fixed and free of the need
> for external updates, it would need to be represented as *data* that's
> loaded as part of the locale file and not as code. Or as a query to a
> (local) service.
>
>> 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.
> That's now how weak symbols work -- they're not a way to add plug-in
> code.
>
> Rich
>
>
Thanks for the clarification. This leaves a query to a local service
the more likely solution since for at least the Hijri (Muslim) and
Hebrew (Jewish) calendars, accurate conversion cannot be based on data
or tables alone.
zg
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.
