On Apr 27, 2016, at 11:51 AM, Random832 <random832@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