[tz] Before 1970 - proposal to change LMT

Stephen Colebourne scolebourne at joda.org
Sat Aug 9 10:58:32 UTC 2014


The TZDB has few issues after 1970 as far as I can see, but before
that date there are debates about what should be included and what
should not.

Options include
- nothing at all before 1970 (but the format demands something...)
- only data that has some reasonable source before 1970
- include data before 1970 even if its source is less than ideal

Ultimately, the problem revolves around the data format (which cannot
realistically be changed) and LMT. In the past there have been various
discussions around LMT with the conclusion that it is a bit of a silly
concept, because it refers to a single location, not a region. But we
are in the position where the format requires it, and it is widely
used (even if that use is accidental rather than deliberate).

Broadly, my position is that where data can be verified pre-1970, such
as in the UK, or my recent Angola email, it should be retained.
Commentary should be added to the data files to justify the data that
is present. Where the data cannot be verified, I am willing to take a
judgement call, provided that the judgement call is not just "we don't
know so lets link it elsewhere".

What I find objectionable is to have a named entity (zone or link)
where the LMT of the named location is replaced by the LMT of some
other location. I understand that others may not care, but it seems
flat out wrong to me (and is key to solving the pre-1970 problem).

Therefore, I'd like to propose a simple alteration to LMT.

I propose that all LMT values in the database are replaced by an new
value, representing what could be described as "averaged/smoothed
regional far past time". In real terms, this means changing all the
LMT values to an appropriate fixed value for that location. Once the
fixed value is chosen, there should be no reason not to retain it
forever.

The intention is that the fixed offset value is the most common
standard offset used by the location, favouring an offset close to the
LMT if ambiguous. The offset chosen would typically be a multiple of
15 minutes, and not contain seconds at all.

To help frame the debate, I produced a list of zones and all their
*standard* transitions (excluding DST) for 2013h;
https://gist.github.com/jodastephen/03487c61782e612db85d

Some examples:
Europe/London
-00:01:15  LMT
Z           1847-12-01
My proposal is to change the LMT value from "-00:01:15" to "Z"

America/New_York
-04:56:02
-05:00      1883-11-18
My proposal is to change the LMT value from "-04:56:02" to "-05:00"

America/Panama
-05:18:08
-05:19:36   1890-01-01
-05:00      1908-04-22
My proposal is to change the LMT value from "-05:18:08" to "-05:00".
If justification for the "-05:19:36" value cannot be found, then that
should be removed.

The net effect of this would be to provide a much more regularized
value for the far past (pre 1850 or later). In most cases, the new LMT
offset would be the same as the first non-LMT offset, resulting in the
removal of a messy transition, leaving only a name change (eg LMT to
GMT).

Advantages
- regularized far past (my experience shows that developers find the
LMT seconds offset confusing when they see it)
- increased stability, once adopted there is no reason for the LMT
value to change
- minimizes churn in the database due to "more accurate" longitude/latitude
- allows the same offset to be used even if the largest city changes in a region
- typically aligns the far past with the first "real" zone definition line
- allows multiple locations to be linked (as per recent changes)
without debate about changing any timestamps in most cases
- when multiple locations are linked, only the start of regular time
is then significant data (where known it should be retained)

Disadvantages:
- changes the meaning of LMT (the name could be possibly be changed to
FPT - far past time)
- loses existing LMT data (it could still be made available in a separate file)
- requires a one-off change

I hope that this proposal can be considered, as it would seem to
address the majority of the issues in a simple and neat way that
benefits most downstream consumers with extra regularity and
stability.

Stephen


More information about the tz mailing list