Subject: Re: [Tzdist] [tz] Regression Tests and Revision Controls

From: Paul Eggert <[email-masked]>
Date: Tue, 12 Aug 2014 22:52:14 -0700

Lester Caine wrote:
> That we need to know which version of tz was used to normalize a record
> has been a given

Although it's been an assumption I doubt whether it's a given, as (A) 
the versioning is complicated, and (B) the version info is often not 
readily available.

Here's a bit more about (A).  The tz database is typically massaged by 
downstream distributions before users see it.  Android discards all data 
outside the 32-bit window (roughly, before 1901 or after 2038).  Other 
distributions discard data before 1970, or add their own zones, or 
cherry-pick upstream changes, or invent their own changes.

Here's an example of versions being distributed today.  Debian currently 
sports four distinct tzdata versions which it calls 2014e-0squeeze1, 
2014e-0wheezy1, 2014e-1, and 2014f-1, each derived from an upstream 
release and with Debian-specific changes; see 
<https://packages.debian.org/search?keywords=tzdata>.  Ubuntu, which is 
downstream from Debian, currently has seven different versions with 
Ubuntu-specific changes, which it calls 2014e-0ubuntu0.10.04, 
2014e-0ubuntu0.12.04, 2013b-1ubuntu1, 2013g-0ubuntu0.13.04, 
2014e-0ubuntu0.13.10, 2014e-0ubuntu0.14.04, and 2014f-1; see 
<http://packages.ubuntu.com/search?keywords=tzdata>.  And Linux Mint, 
which is downstream from Ubuntu, has its own four versions 2010i-1, 
2011n-0ubuntu0.11.10, 2013b-1ubuntu1, and 2014b-1; see 
<http://community.linuxmint.com/software/view/tzdata>.

That's just three distributors; there are dozens more.  And if you care 
about Java, PHP, Go, etc., then multiply everything by another factor, 
as these subsystems have their own database copies with their own 
idiosyncrasies.  Good luck to anybody who wants to keep track of what 
all those versions actually mean.

And that's just (A).  I suspect that (B) is a bigger kettle of fish.

---

From: Lester Caine <[email-masked]>
Date: Wed, 13 Aug 2014 08:10:32 +0100

> And that's just (A).  I suspect that (B) is a bigger kettle of fish.

All that just strengthens the argument for a properly managed
distribution system? And perhaps at the same time the major hole caused
by only providing a time offset in the browser header rather than a
users actual timezone can be address? It's not a lot of use giving
correct timezone data if you have no idea of the clients offset in 6
months time :(

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk