[tz] tz abbreviations / zdump for programmers
boruch_baum at gmx.com
Mon Jun 4 18:39:55 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 06/04/2012 01:00 PM, Paul Eggert wrote:
> Thanks for the email. Some comments:
>> 2.2] zone.abbr.tab proposal
> This seems better, since the file could be maintained automatically
> from the existing data, with a new script or whatever.
> I didn't understand this table's "localedef" column though; isn't
> the tz info independent of locale? Or are you anticipating a
> future feature in which time zone abbreviations depend on locale?
I'm not terribly certain, since I'm new to this myself. My
considerations / fears were:
1) having a way to know how the 'owners'/residents of a timezone
format their time/date information.
2) multilingual zones - eg. Do the French in Quebec have the same
TZ name and abbreviation as the Anglos there?
2) multi-character set zones - eg. Israel, where both Arabic and Hebrew
are official languages (and English isn't) - Do the locals use
their native character set representations of the timezone
abbreviation and name? I would want to respectful of that, to the
extent possible. In the case of Israel, I remember dst referred to
only as שעון קיץ.
BTW, I made one important omission in my proposal for zone.abbr.tab -
I left out a field for the tz_name (eg. Asia/Baku).
Also, for the parochial need of my libhdate collection, it would be
useful to also include on each zone.abbr.tab line the coordinate
information already present in the zone.tab file.
>> int zdump( /// returns TRUE on success, FALSE on
> How about instead having a little function that, given a time,
> finds the next (or the previous) transition time?
This sounds familiar. It may be that I saw that approach being taken
in the current codebase. This would not be optimal for me (see below),
but if there is a need for it, I could do it also.
> That would allow iterations through transitions that'd be much
> easier than poring through the output of the proposed 'zdump'
Here I disagree because:
1) with your approach, each iteration through transitions would require
a separate call to the function. My approach has the advantages of
being only a single call, a single file open and parse, and an
immediate indication of how many transitions to expect over the
interval being processed.
2) I'm presuming that the caller will be processing dates in either
chronological or reverse-chronological sequence, so it should be
very simple to work with the output. I could provide a snippet on
the man page.
3) Your suggestion to return the next transition wouldn't be useful
for a user who already knows the range of date/times she wishes
to process, if that next transition is out of her desired interval.
The 'zdump' proposal, in that case, would return just the information
BTW - the current man page for zdump(1) omits the loyear,hiyear option.
Compare the 'man 1 zdump' with 'zdump --help'
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the tz