[tz] tz abbreviations / zdump for programmers

Boruch Baum boruch_baum at gmx.com
Mon Jun 4 18:39:55 UTC 2012

Hash: SHA1

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 
>> failure
> 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' 
> function
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

Version: GnuPG v1.4.12 (GNU/Linux)


More information about the tz mailing list