[tz] tzfiles contain Unix epoch for the first transition time

[Jon Skeet]

Just as an aid to verifying this, could you tell us which copy of the data
you're using (as each file contains two or three copies of the information).

A hex dump of the relevant section would be really handy, too.

Jon


On 13 August 2015 at 17:21, Eric Erhardt <Eric.Erhardt at microsoft.com> wrote:

> I am working on enabling the .NET TimeZoneInfo class to read time zone
> information from tzfiles.
>
>
>
> I’ve hit a snag with the latest tzdata 2015f.  (I’m not sure when this
> change started, but the problem doesn’t occur with the tzfiles that are
> shipped with an Ubuntu 14.04 distribution.)
>
> The problem is that the 2015f version of the tzdata contains an initial
> "Transition Time" that is out of order. The beginning of the
> America/Chicago tzfile looks like the following:
>
> *Transition Time*
>
> *Transition Offset*
>
> 01/01/1970 00:00:00
>
> -05:50:36
>
> 11/18/1883 18:00:00
>
> -06:00:00
>
> 03/31/1918 08:00:00
>
> -05:00:00 DST
>
> 10/27/1918 07:00:00
>
> -06:00:00
>
> Notice the first entry is for 1970, and then the next entry is for 1883.
> This breaks the documentation in 'man tzfile':
>
> The above header is followed by tzh_timecnt four-byte values of type long, *sorted
> in ascending order*. These values are written in "standard" byte order.
> Each is used as a transition time (as returned by time(2)) at which the
> rules for computing local time change.
>
> This causes the TimeZoneInfo parsing code to throw an exception because it
> is assuming these transitions are sorted in ascending order.
>
> Is this an intentional change in the tzfiles?  If so, will the tzfile man
> page be updated for this change?
>
> Eric Erhardt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150814/4e54979a/attachment-0001.html>