[tz] tz abbreviations / zdump for programmers

[Boruch Baum]

-----BEGIN PGP SIGNED MESSAGE-----
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.
OK.
> 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
   required.

BTW - the current man page for zdump(1) omits the loyear,hiyear option.
   Compare the 'man 1 zdump' with 'zdump --help'

- -- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJPzQD4AAoJEDvrUfDmCx9LplwP/3nJzMJqfAKP5fhaVUzZxMbE
fDOr8W/k9eqJ8K78jkb5MC4JfzVd7nmCIHccl+AoHsTmLrqYjL+otkjxyEjgtga/
BwsA05Ap0UPGjoisOuN5UVBRKWOyZUxFFOVv6U+WRRjLw+6SC/UQ43yspHNcpcti
iyet2P6qs25k1SRKYKz9PqeIpxKGuUbclLm3qlIK2wrkQuowmHmnaR60vgfmBshF
LUbBWUHf8aVs9GvW+wGyfSNkS/EhylxRHhJhYmAgjLFjDXu4jLzj67cSWvn/SAR9
mU7qdjA0UA8DcUKOG8C9at2bAjA/5nxhMqI5eFm03ZPLjQI6Anajh0rh2JucAWzj
y2HwihioFrwCTqUX+59PO0BjtrMH2kdIA5c5jd4z27Wq9zmlVJobA8VMGr3mphqE
K1vO/rE10dtpy5uAnoZ+Rj4S3T9yX/bIb/rzN21lYhuktDEvxss9JfgzhBsdMvg9
2DCj9lmAVsvUeBjwidm+XpomKxKPC3dYES9kydrArgT+ZdBPMcQD2heZ2f9rvFIi
0A1t8Y8XJe8iZlcfcr/4ymXWwX50xOAZ0zz/9iWbaS3LJo9V91hQtaTTwqK94PoW
IlsB2mdfE2Rk8ykVYijkxdmMwQJJkt4VNtusS0Mbudnz5lDCgY1BqE9TOSJ/cBo+
4RE0ZBOPoRC2K71ExmMh
=0LHE
-----END PGP SIGNATURE-----