History of TODO

Pulling together available material to cross reference it.

1. Import base tz data in a format that can be extended
2. Set up base 'country' table using ISO3166 Data
3. Import location data along with coordinates
4. Plan wiki and directory to archive supporting documentation
5. Produce historic tz database

Pulling together available material to cross reference it.

1. Import base tz data in a format that can be extended
2. Set up base 'country' table using ISO3166 Data
3. Import location data along with coordinates
4. Plan wiki and directory to archive supporting documentation
5. Produce historic tz database

The crux to my own 'problem' with all of this I have tz2014h on the system ... 'latest' tells me it's tz2014i so ALL I need is the difference between 'h' and 'i' and currently there is no service to provide it. The current tzdist workgroup draft still proposes republishing each timezone which has changed and that creates a lot more traffic than necessary.

The following is not the current diff on those versions, but just an example.
Currently I ask for the 'changedsince' list and it gives me all the TZID's which have changed, but if you go back to the source, perhaps just one modern generic rule has a change say Central European Time for example. If I have several dozen city related rules it will list all of them since each has to be expanded with the new element. The States is probably another example of several hundred potential TZID's which may be affected by just one current generic change?
Now if the ZTIMEZONE format could handle 'nesting' ... which is what the raw TZ data does ... we could just send the CET change and the client ( or slave server ) can pick up the change and assess if it affects things locally. All of the historic material can then be managed separately and does not need to be retransmitted every time.

An example of how to get this badly wrong is provided by geonames which produces nightly updates to it's cross reference which includes the current TZ id (thankfully still including the pre 1970 list of ID's ) but it ONLY publishes the whole database plus ONE last issue. So if you mis a night ... At least with the openstreetmap data one can get the incremental versions you have missed. But at some point a service can be set up to maintain just the TZID element of geonames along with an historic track for the history of a locations change of TZID. THIS could quite easily provide all of the pre-1970 material to completely map the sequence for a location, something which the TZ data is not 'chartered' to provide. Linked with OSM one has the geographic mapping as well.

For international websites we NEED that the current useless 'tzoffset' is replaced with a valid and universally recognised TZID and I will continue to use TIMEZONE to describe this since to me this  is now a single word. Once tzdist is finally published we will have a base for this element of the process, but we still need a reliable meens of identifying the timezone rules currently used at a location. That a location may now be using different rules to the longer term past is only relevent if one IS working with historic material, but there is no need to weight down the timezone database with that historic baggage as long as an alternate menas if identifying it is available.