[tz] Before 1970 - proposal to change LMT
scolebourne at joda.org
Mon Aug 11 00:48:11 UTC 2014
On 11 August 2014 00:59, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> 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.
> This objection seems to be based on a misunderstanding of what the LMT
> entries were always supposed to mean. They never meant anything like "the
> time at this location was exactly 7 hours, 52 minutes and 58 seconds before
> GMT" (to use America/Los_Angeles as an example). Instead, they meant that
> the time was not closely specified: different people at that location would
> not have cared about minor differences in GMT offsets, or (if pushed to be
> specific and if knowledgable about the topic) would even have disagreed
> about what the GMT offsets should be.
> In hindsight the tz database format should had have a specific notation for
> this. But it doesn't, so we use LMT entries as stand-ins. Their exact GMT
> offsets do not matter. It's similar to the zzz notation that we use for
> places while uninhabited. I suppose one could argue that the LMT and zzz
> notations are both abuses of the format, but we needed *some* way to say
> that the local time was not closely specified or was undefined, and that's
> what we came up with.
This seems to be missing the point (again). It does not matter what
the intention of LMT in the data format was. What does matter is what
it has actually been used for! In reality, the LMT value is widely
available as an actual, visible, usable value in applications in many
different programming environments. By all means say that we should
not be in this mess, but we are, and the proposal is an incredibly
simple way to reduce the effects.
The concept that LMT somehow means "undefined" has been totally lost
at this point. It is also an unhelpful answer, as the programming
environments need *some* answer for time-zones in the far past, and
right now LMT is the obvious one to pick up. Simply changing the
notation from LMT to undefined would not stop the need that
programming environments have for a far past value.
(By the way, if a programming environment wanted to choose a value for
the far past that was not LMT, the chances are that they would choose
a smoothed value, exactly as proposed, because that is more in line
with the expectations of normal developers)
>> The net effect of this would be to provide a much more regularized
>> value for the far past (pre 1850 or later).
> This makes it sound like the proposed notation would be more misleading than
> the current one, as it would suggest an even-more-regularized past than the
> current one does. We shouldn't give users the incorrect impression that
> long-ago timekeeping was tidy.
All values for the far past are misleading to some degree, "more
misleading" is subjective. The proposal simply chooses a value that
would be beneficial to the long term maintenance of the tzdb data, by
replacing an unstable value by a stable value. That way, most of the
link discussion goes away, for example because all of West Africa
would then share the same smoothed LMT value.
Finally, I will note that for those users who already understand that
LMT data means "undefined", the proposal makes no difference. Those
users can carry on interpreting LMT in that way. However, for those
users that do interpret LMT as an actual real offset to be used for
the far past (the vast majority of programming environments) the
proposal provides a simpler, clearer answer.
More information about the tz