[tz] Proposal: validation text file with releases
Howard Hinnant
howard.hinnant at gmail.com
Wed Apr 27 16:58:55 UTC 2016
On Apr 27, 2016, at 11:51 AM, Random832 <random832 at fastmail.com> wrote:
>
> What's wrong with zdump's output format?
>
> $ zdump -v Africa/Maseru
> Africa/Maseru -9223372036854775808 = NULL
> Africa/Maseru -9223372036854689408 = NULL
> Africa/Maseru Sun Feb 7 22:07:59 1892 UTC = Sun Feb 7 23:59:59 1892
> LMT isdst=0 gmtoff=6720
> Africa/Maseru Sun Feb 7 22:08:00 1892 UTC = Sun Feb 7 23:38:00 1892
> SAST isdst=0 gmtoff=5400
> Africa/Maseru Sat Feb 28 22:29:59 1903 UTC = Sat Feb 28 23:59:59 1903
> SAST isdst=0 gmtoff=5400
> Africa/Maseru Sat Feb 28 22:30:00 1903 UTC = Sun Mar 1 00:30:00 1903
> SAST isdst=0 gmtoff=7200
> Africa/Maseru Sat Sep 19 23:59:59 1942 UTC = Sun Sep 20 01:59:59 1942
> SAST isdst=0 gmtoff=7200
> Africa/Maseru Sun Sep 20 00:00:00 1942 UTC = Sun Sep 20 03:00:00 1942
> SAST isdst=1 gmtoff=10800
> Africa/Maseru Sat Mar 20 22:59:59 1943 UTC = Sun Mar 21 01:59:59 1943
> SAST isdst=1 gmtoff=10800
> Africa/Maseru Sat Mar 20 23:00:00 1943 UTC = Sun Mar 21 01:00:00 1943
> SAST isdst=0 gmtoff=7200
> Africa/Maseru Sat Sep 18 23:59:59 1943 UTC = Sun Sep 19 01:59:59 1943
> SAST isdst=0 gmtoff=7200
> Africa/Maseru Sun Sep 19 00:00:00 1943 UTC = Sun Sep 19 03:00:00 1943
> SAST isdst=1 gmtoff=10800
> Africa/Maseru Sat Mar 18 22:59:59 1944 UTC = Sun Mar 19 01:59:59 1944
> SAST isdst=1 gmtoff=10800
> Africa/Maseru Sat Mar 18 23:00:00 1944 UTC = Sun Mar 19 01:00:00 1944
> SAST isdst=0 gmtoff=7200
> Africa/Maseru 9223372036854689407 = NULL
> Africa/Maseru 9223372036854775807 = NULL
>
> Cons:
> - A bit verbose
> - technically uses instants (from before and on each transition) rather
> than spans.
> - The NULLs are a bit mysterious
> - I'm personally not sure *exactly* how it finds the transitions, and in
> particular I'm not sure if it will reliably find multiple transitions
> per day
>
> Pros:
> - Already exists
> - Is already written in C, and already installed on many systems
> - Does not depend on any implementation internals
One of the use cases I find valuable is comparing the output from two sequential versions of tzdata. Therefore human-readability of the format ranks very high for me. I can read Jon’s format far more easily. One entry per transition is inherently easier to read. I see no reason to repeat the timezone name for each entry. Furthermore some of the zdump output is not referring to data contained in tzdata (that I can tell). Rather it appears to refer to details of tzcode (e.g. 9223372036854775807 == 0x7FFFFFFFFFFFFFFF).
I would not be opposed to tweaking the format of the validation file. However the zdump format does not look like a step forward to me.
I wouldn’t mind seeing the validation file start out with the tzdata version. And I wouldn’t mind seeing the leap second data appended. I would have no objection to subbing in ‘ ‘ for ’T’ in the transition timestamp. I would like to maintain an empty line between timezones.
I would object to any data appearing after the abbreviation unless the abbreviation is padded with spaces to make the subsequent data appear in a consistent column. And generally, I highly value consistent columns for data.
I can sympathize with “Already exists”. But from where I sit, so does Jon’s format.
Howard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/tz/attachments/20160427/65d47608/signature.asc>
More information about the tz
mailing list