[tz] Proposal: validation text file with releases

[Jon Skeet]

I'd say those cons are pretty significant - I find it very significantly
harder to read than the format I've propsed. I'm also confused by your
"pro" that it doesn't depend on any implementation details, but it really
*exposes* the implementation details in naming ("isdst" and "gmtoff" for
example, along with the mysterious huge numeric values).
The aim is to have a format which is easy and natural to generate on
*multiple* platforms, so that authors of other code parsing the data can
validate against it. That would be a *very* unnatural format to generate
from .NET with either Noda Time or TimeZoneInfo, or from Java 7, Java 8 or
Joda Time.

I'd certainly be in favour of my "zicdump" C# code being rewritten in C
(and maybe even offered as a different format for zdump, based on a
command-line flag) but I see very little benefit in adopting a format which
doesn't seem to have been designed for the same purpose as the tzvalidate
one.

Now having said all that, I'm very happy to tweak the format (and have
already done so based on earlier suggestions) - but I wouldn't want to use
the zdump -v format just because it already exists, if it's not really fit
for purpose.

Jon


On 27 April 2016 at 16:51, Random832 <random832 at fastmail.com> wrote:

> I missed this the first time around...
>
> > On 11 July 2015 at 11:35, Jon Skeet <skeet at pobox.com> wrote:
> >
> > > Background: I'm the primary developer for Noda Time <
> http://nodatime.org> which
> > > consumes the tz data. I'm currently refactoring the code to do this...
> and
> > > I've come across some code (originally ported from Joda Time) which I
> now
> > > understand in terms of what it's doing, but not exactly why.
> > >
> > > For a little while now, the Noda Time source repo has included a text
> > > dump file
> > > <
> https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData/tzdb-dump.txt
> >,
> > > containing a text dump of every transition (up to 2100, at the moment)
> for
> > > every time zone. It looks like this, picking just one example:
> > >
> > > Zone: Africa/Maseru
> > > LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00)
> > > SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00)
> > > SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00)
> > > SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01)
> > > SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00)
> > > SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01)
> > > SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00)
>
> ...
>
> > > Any thoughts? If the feeling is broadly positive, the next step would
> be
> > > to nail down the text format, then find a willing victim/volunteer to
> write
> > > the C code. (You really don't want me writing C...)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160427/8dc0a6dc/attachment.htm>