[tz] Proposed reversions, for moving forward

[Paul Eggert]

Lester Caine wrote:
> if the answers returned when checking historic data on a
> timezone depend on what data has been loaded then we are back with the
> problem!

This is inherent to the current way the tz database is used.  Different 
software distributions use different versions of the tz database.  They 
install the tz database with different build-time options, getting 
different sets of names.  And distribution-specific patches can greatly 
affect old time stamps: for example, Android discards all parts of the 
database before 1901 (and after 2038!).

> I'd rather see a 'not available'
> rather than a 'this is todays guess'

Even for future timestamps?  Most of them are "today's guess".

> I'd just be happy with hour correct.

The changes in question are pretty much all in that category.

> I CAN see a
> case for storing the version of tz used along with the timezone

Absolutely, if one is serious about provenance.  One should record the 
tz database version (including local changes and options) as part of the 
provenance.  One way to record this sort of information is OPM 
<http://openprovenance.org/>.  The tz database version is only a part of 
this problem, as in the typical case one also needs to record the C 
library version, kernel version, hardware version, etc.