Subject: [Tzdist] LMT transition

From: Lester Caine <[email-masked]>
Date: Mon, 18 Aug 2014 21:00:43 +0100

Slowly working my way through draft-douglass-timezone-service and the
thing that I seem to be missing is an indication that a timezone has
actually started. This is tagged on tz with an LMT value so that prior
to this transition a local offset will be calculated based on longitude
of the location, while after it's provided by a designated longitude for
the whole zone. LMT Location is a useful optional value to include in a
full tz definition.

While I would anticipate that 'truncated' servers will be post 1970, the
situation where an older truncation may well result in individual
results for some timezones that are 'undefined'. 'tzid-not-found' is
probably not a suitable error in this case, but I'm not sure this
situation is even covered?

This is also an area where some third party service will be needed to
map locations to timezones or provide a longitude value for an LMT
fallback as an update to the 'undefined' error although I'd personally
prefer a server which actually handles this situation integrally.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Aug 2014 11:15:36 -0400

Hi Lester,

> the whole zone. LMT Location is a useful optional value to include in a

First off LMT is not useful for a calendaring and scheduling system because 
there would have to be exact agreement on what the geo "reference point" 
for LMT is between all the attendees of the event to ensure they agree on 
the same time. If that is the case, they might as well just use the UTC 
value derived from the LMT+geo reference. As it stands iCalendar has no 
facility for handling LMT - but it deals with UTC just fine.

I think the same thing is probably true for operating systems - they can 
synthesize an LMT via UTC for their known geo location.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 17:19:53 +0100

On 20/08/14 16:15, Cyrus Daboo wrote:
> First off LMT is not useful for a calendaring and scheduling system
> because there would have to be exact agreement on what the geo
> "reference point" for LMT is between all the attendees of the event to
> ensure they agree on the same time. If that is the case, they might as
> well just use the UTC value derived from the LMT+geo reference. As it
> stands iCalendar has no facility for handling LMT - but it deals with
> UTC just fine.
> 

This may just be a matter of terminology? During the period between the
use of a central time, and formal agreement on 'GMT' as a base,
countries used their own 'LMT' based on a prescribed location. The tz
comments document a lot of these. We know that the history is not
complete, but there are a substantial number of 'timezones' documented
prior to the formal standard adopted in 1884. The tz system has
relevance to these historic records just as it does to scheduling
meetings in the next few years ... and so tzdist needs to handle the
whole range of data rather than a blinkered view starting in 1970!

---

From: Paul Eggert <[email-masked]>
Date: Wed, 20 Aug 2014 11:10:48 -0700

Cyrus Daboo wrote:
> operating systems ... can

It's no big deal, but in the tz database "LMT" doesn't mean "local time 
can be derived from geolocation".  It's more like "we don't know what 
the local time was but the tzdata format requires a value, so here's a 
guess".  Although geolocation could produce a better guess, it could be 
worse too.  In practice almost nobody actually tried to observe local 
mean time during the historical periods in question, so in some sense 
inferring the use of LMT from geolocation is almost certainly wrong.

Anyway, surely these historical trifles are out of scope for the time 
zone service protocol.  The protocol's job is to move the data entries 
around, not to reargue fine points about what they mean.

---

From: Mike Douglass <[email-masked]>
Date: Wed, 20 Aug 2014 14:31:40 -0400

> around, not to reargue fine points about what they mean. 

Absolutely. The tz protocol is intended to be (and we hope is) data 
agnostic. We spent a long time talking about registering publishers and 
allowing the specification of publishers but for the time being just 
being able to deliver Olson data would be a huge step forward.

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 20:46:26 +0100

> being able to deliver Olson data would be a huge step forward.

tzdist protocol ;) tz IS the data ...

The only bit I'm trying TO flag is is spotlighted in Cyrus's sample. The
1883 transition is from an LMT value for New York to a GMT based
timezone. For some locations such as New York this transition is from an
unmanaged LMT while other locations such as Paris, there was a previous
LMT based standard timezone in use until 1911. Britain started using a
standard time in 1880 but there were other standards prior to that, so
some means of flagging what pre-dated the 1884 agreement would be
helpful? Material that still needs incorporating into tz ...

---

From: Ken Murchison <[email-masked]>
Date: Wed, 20 Aug 2014 15:55:57 -0400

> helpful? Material that still needs incorporating into tz ...

Assuming that I'm understanding the issue correctly, if such a flag ever 
appears in the IANA timezone data (or some other source), a mapping for 
that flag to a new or existing iCalendar property for inclusion in 
VTIMEZONE can certainly be made.  But I think such a mapping is outside 
the charter of this WG.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2014 22:41:35 +0200

On 8/20/14, 9:55 PM, Ken Murchison wrote:
>
> Assuming that I'm understanding the issue correctly, if such a flag
> ever appears in the IANA timezone data (or some other source), a
> mapping for that flag to a new or existing iCalendar property for
> inclusion in VTIMEZONE can certainly be made.  But I think such a
> mapping is outside the charter of this WG.

The content of the database itself – perhaps modulo any necessary
encoding – probably should be outside the scope of this group, if we can
avoid it.  This means that draft-douglass-timezone-service needs to be
careful to minimize the use of semantic searches that might use fields
in the database.  Right now my reading is that you are on the correct
side of that line, at the moment.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Wed, 20 Aug 2014 21:48:49 +0100

On 20/08/14 20:55, Ken Murchison wrote:
> But I think such a mapping is outside the charter of this WG.

Hence my original post about 'passing the buck'. The base data range
that the protocol is treating as un-truncated has no limit, so since the
IANA timezone data default is truncated at 1970, that is already
covered. However the charter document allows for an unlimited time
range, which the tzdist protocol would have to support? Which then
throws up the problem of timezoneid values outside the range of the
current full zone table in tz ...

Restrictions to what is supported need to be fully documented.