[tz] State of the tzdb
scolebourne at joda.org
Tue Sep 3 10:00:27 UTC 2013
We're a lot further forward now to regaining stability, but there are
a few points still outstanding.
1) Should there be one zone ID in the main files (not "backward") for
each inhabited ISO-3166 code?
I've argued for this as a reinstatement of a rule of 16 years standing
which is no more than common sense.
Paul has argued against.
2) Zone ID for America/Shiprock
3) Zone ID for Antarctica/South_Pole
At a minimum, the "backward" link needs to point to McMurdo
4) Recognise correct usage of "backward" file
As per ECMAscript:
the "backward" is, and will continue to be, used for canonicalization
- ie. identifying which IDs can be normalized away.
As such, the tzdb needs to be very careful about cross-ISO-3166 links
placed in the "backward" file (IMO there should be none to avoid
political offence via canonicalization). The use of "backward" should
be further documented in Theory to indicate its usage as a
canonicalization file, and to indicate that the entire tzdb data set
must make sense if the "backward" file is not processed (thus no lines
in zone.tab should point to an ID in "backward")
5) Pre-1970 data
Some of this seems uncontroversial at this point (don't remove data,
don't create new IDs just for pre-1970). Some of it is still under
discussion. Only enhancement of existing IDs is necessary to the
applications I work with.
As noted in the other thread, removing IDs that only differ in LMT is
harder than initially thought, as the start of fixed offsets and the
name of fixed offsets are pieces of data covered under the no deletion
rule. As such, it is unlikely that there are many possibilities for
6) ... anything I've forgotten?
Finally, I'm sorry I've had to spend so must list time discussing
this. Unfortunately, this data is just too important to me and the
applications/langauages downstream of me to allow me to not object
More information about the tz