June 4, 2012
6:39 p.m.
-----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-----