[tz] Proposal: validation text file with releases

[Howard Hinnant]

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>