From: "writeonce@midipix.org" <writeonce@midipix.org>
To: musl@lists.openwall.com
Subject: Re: Locale bikeshed time
Date: Wed, 23 Jul 2014 22:59:15 -0400 [thread overview]
Message-ID: <53D07683.9010209@midipix.org> (raw)
In-Reply-To: <20140724022408.GH11570@brightrain.aerifal.cx>
On 07/23/2014 10:24 PM, Rich Felker wrote:
> On Wed, Jul 23, 2014 at 10:16:40PM -0400, writeonce@midipix.org wrote:
>>>> 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.
>>>
>> 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.
> How so? All code is fundamentally data/tables. Is your point that the
> current data is not sufficient to compute all future times (in which
> case updated data would be needed but sufficient) or just that the
> algorithms are moderately complex (in which case a the data would have
> to represent a nontrivial computational language).
For one thing, the algorithms for past dates are moderately (or somehow
more than moderately) complex. This pertains to both the Hijri and
Hebrew calendars. With respect to future dates, in the most traditional
Muslim countries the first day of the month is predicted via astronomic,
yet confirmed via traditional means (observation of the new moon). In
those countries you might therefore find out "in real time" whether
tonight is the 1st of the next month, or the 30th of the current one.
For date conversion to be accurate, then, you would have to get your
data updated on a monthly basis, which at least for me makes a local
service the better solution. Obviously, things would have been much
easier if the wise and elderly had designed their calendars with an ISO
libc in mind (a bug in the prophet utility?), but I personally wouldn't
dare trying to change them;-)
>
>
> In any case this is probably quite low priority. I'm not aware of any
> other libc supporting these features or any significant demand for
> them. So it's a neat topic to discuss, but getting pretty far off
> topic from the topic at hand (locale support in 1.1.4).
>
> Rich
>
>
Of course. That's why I suggested to define only the interfaces (or
hooks, which now I understand are not an option), and not worry about
the implementation.
zg
next prev parent reply other threads:[~2014-07-24 2:59 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 18:49 Rich Felker
2014-07-22 20:10 ` u-igbb
2014-07-22 20:35 ` Rich Felker
2014-07-23 9:50 ` u-igbb
2014-07-23 16:39 ` Rich Felker
2014-07-23 19:25 ` u-igbb
2014-07-23 21:01 ` Rich Felker
2014-07-24 15:35 ` u-igbb
2014-07-24 16:01 ` Rich Felker
2014-07-24 19:24 ` u-igbb
2014-07-24 20:15 ` u-igbb
2014-07-24 22:02 ` Rich Felker
2014-07-25 9:06 ` u-igbb
2014-07-25 20:15 ` u-igbb
2014-07-25 22:32 ` Rich Felker
2014-07-26 7:25 ` u-igbb
2014-07-26 8:03 ` Rich Felker
2014-07-26 9:06 ` Jens Gustedt
2014-07-26 9:25 ` Rich Felker
2014-07-26 9:38 ` u-igbb
2014-07-26 17:47 ` Szabolcs Nagy
2014-07-26 18:23 ` Rich Felker
2014-07-26 18:59 ` u-igbb
2014-07-26 19:14 ` Rich Felker
2014-07-26 18:56 ` u-igbb
2014-07-26 19:30 ` Rich Felker
2014-07-27 7:28 ` u-igbb
2014-07-26 20:43 ` Rich Felker
2014-07-27 7:51 ` u-igbb
2014-07-27 8:00 ` Rich Felker
2014-07-27 8:24 ` u-igbb
2014-07-23 23:22 ` writeonce
2014-07-23 23:38 ` Rich Felker
2014-07-24 1:07 ` writeonce
2014-07-24 1:57 ` Rich Felker
2014-07-24 2:16 ` writeonce
2014-07-24 2:24 ` Rich Felker
2014-07-24 2:59 ` writeonce [this message]
2014-07-22 20:17 ` Laurent Bercot
2014-07-22 20:36 ` Rich Felker
2014-07-23 22:03 ` Laurent Bercot
2014-07-23 22:12 ` Rich Felker
2014-07-24 15:38 ` u-igbb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D07683.9010209@midipix.org \
--to=writeonce@midipix.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).