Subject: [Tzdist] Is 'version' a required?

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 09:24:57 +0000

This is one simple question which we seem to keep working around rather
than asking formally?

Cyrus is of the opinion that we only need the latest version of TZ in
order for tzdist to provide a viable system of distribution. I've come
to tzdist simply because the LACK of a reliable access to previous
versions has resulted in broken archival data, but also the current
problem of not being able to ensure that users of current event
calendars where the version of TZ data has changed since publishing it.

What are other peoples view on this?

-- 
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: Ken Murchison <[email-masked]>
Date: Tue, 16 Dec 2014 09:20:03 -0500

On 12/16/2014 04:24 AM, Lester Caine wrote:
> order for tzdist to provide a viable system of distribution.

I happen to agree with Cyrus on this, especially for the original use 
case in the charter which is iCalendar and CalDAV.  tzdist clients and 
servers are expected to be updated frequently enough where they will 
always have correct TZ data prior to an event (Except in the case of a 
very short-term TZ change on the order of less than a day where only 
out-of-band communication between parties can be expected to resolve any 
time discrepancies).

> I've come

I'm still confused on this.  Are you saying that schedules are published 
for future events, the events will not or did not take place on the 
previously prescribed time, but the published material isn't 
re-published with the correct times?  I can't see the non-republishing 
of schedules happening with my favorite football team (American or 
otherwise), my local theater, airline flights out of New York, Beijing, 
or Melbourne, etc.  I think people have a reasonable expectation that 
published times of events will be accurate using the TZ data that is 
current at the time of the event.  The thought that a publisher of 
events would expect/require consumers to have to fetch an outdated 
version of TZ data to figure out what time an event actually happened or 
will happen seems odd to me.

That being said, if there is a reason to access older versions of TZ for 
archived event data or for forensic purposes, I view this as an 
extension to tzdist, not a requirement for the base spec, especially 
given the fact that it sounds like "raw" TZ data (e.g. 
application/tzdata) would be the preferred data format for this use case 
anyways.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Dec 2014 15:29:25 +0100

I agree with Cyrus but for different reasons.  It is possible that no
version # will exist.  In any incrementally updated database this is
true, and it is possible that the TZ maintainers might choose to move to
that model in the future.

Eliot

On 12/16/14, 3:20 PM, Ken Murchison wrote:
> out-of-band communication between parties can be expected to resolve
> any time discrepancies).
>
>
>
>> I've come
> I'm still confused on this.  Are you saying that schedules are
> published for future events, the events will not or did not take place
> on the previously prescribed time, but the published material isn't
> otherwise), my local theater, airline flights out of New York,
> Beijing, or Melbourne, etc.  I think people have a reasonable
> expectation that published times of events will be accurate using the
> TZ data that is current at the time of the event.  The thought that a
> publisher of events would expect/require consumers to have to fetch an
> outdated version of TZ data to figure out what time an event actually
> happened or will happen seems odd to me.
>
> That being said, if there is a reason to access older versions of TZ
> for archived event data or for forensic purposes, I view this as an
> application/tzdata) would be the preferred data format for this use
> case anyways.
>

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 14:54:54 +0000

> out-of-band communication between parties can be expected to resolve any

Out of band action is the only way to fix the problem. It's flagging to
users that there is a potential problem which requires that contact
which is the race hazard I'm worried about. I don't see how this can be
cleanly identified without 'version'.

> will happen seems odd to me.

If one assumes that the TZ data served up by every publisher is
identical and everything published is always correct, then there can
never be a problem. If I download a calendar for say a new holiday
location for March next year and they are using a different TZ publisher
to the one I normally use then the TZid may well be different. So I need
a different set of data ... and I need the set that matches that
calendar ... but I may not now look at the calendar again until closer
to the event. When I do I need to know if anything has changed? Perhaps
the location has now dropped DST or gone to 'double summer time'. It's
the TZ data difference between last time and now which flags the
potential problem, and 'yes' the changedsince refresh of the tzdist
cache will update the TZid data, but using published versions in that
allows one to see just what has changed.

> application/tzdata) would be the preferred data format for this use case

If tzdist is ONLY to be used with iCalendar event data then yes we need
a TZdist system for every other application of TZ data?

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 15:08:55 +0000

> that model in the future.

TZ has a well documented version release process, and there already
exists an historic release archive. Just not one we can reliably use as
yet. As of today we are using 2014j, but there are already a few items
which will form 2014k or perhaps 2015a.

The problem is that not everybody used the data exactly as published so
some differences may exist in what was used in the past but tagged with
a legacy version number. Going forward, a tzdist publisher using TZ data
would only publish the correct TZ data and we can then reliably use that
going forward. Essentially TZ is only available AS a series of
documented versions so we only need to maintain synchronisation with
those fixed points.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Dec 2014 16:40:55 +0100

> which will form 2014k or perhaps 2015a.

This is how it works today, and only for the TZ database.  Now, I don't
want us to have to think too far afield from how things work today, but
if this mechanism succeeded, there would be no reason to wait for an
official TZ release for a single entry.  That would be up to the
publisher (whoever that is).  Also, while the TZ database may be the/a
source of truth, it doesn't mean that it is the publisher of the
information.  As I mentioned previously, any versioning has to be
addressed in some protocol independent (and schema dependent) manner.

> documented versions so we only need to maintain synchronisation with

Assuming the world stays that way, and that the TZDIST service rolls out
that way for everyone.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 16:19:44 +0000

> addressed in some protocol independent (and schema dependent) manner.

Actually I agree on the point about the not waiting for the official
release. If one of the current pre-release patches on TZ is important
for current data, then it should be pushed out. That was my point about
'sub-version'. The problem with having hundreds of releases is when
working with the historic material. You do not want to have to maintain
every possible sub-version, so the consolidated releases are important.
Published versions that can be relied on historically makes support
easier to maintain.

Another point that should perhaps be made is that as has already been
mentioned, many users do not have continuous internet connections.
Version simply allows continuity across breaks in time and server used.
The off-line copy of a calendar may match the off-line tzdist version,
but when re-syncing one can at least see if either set needs updating.
Assuming a calendar is always up to date can't be relied on, so knowing
what version it IS valid to is essential.

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Dec 2014 09:32:22 -0700

On 12/16/2014 02:24 AM, Lester Caine wrote:
> ...

I don't see a need to be able to fetch any specific old version of TZ 
data for any calendar application or OS.

The only version I think is needed is the last-modified value in the 
VTIMEZONE property so OS's and calendaring applications know if they 
have the latest version.

I think the bigger problem is every OS or application pinging the 
tzdist-server daily or each time it starts. That's just going to be a 
ton of traffic. Developers will (1) ping at some interval, or (2) ignore 
it like they do now and wait for the application update (never?) or OS 
update.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 16 Dec 2014 11:43:04 -0500

Hi Lester,

> mentioned, many users do not have continuous internet connections.

I don't like that argument because there are many other things that can get 
out of sync when there is no connection (and indeed are far more likely). 
In particular, if you are offline and the organizer changes the time or 
location of an event, then you are in just as much trouble as you would be 
if the time zone changed and you did not know about it. I would postulate 
the former type of change is a lot more frequent than the later.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 16:51:05 +0000

> data for any calendar application or OS.

If you are only looking at current data then you only need the current
offsets. In ten years time if you have a set of material archived today
using the current version then you need access to that old version.
Since one may well be on a new computer by then we need a means of
accessing the data. Relying on the OS having already loaded the history
would be nice, but being able to get it as part of a TZ distribution
service somehow seems the right thing to be doing?

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 17:06:43 +0000

On 16/12/14 16:43, Cyrus Daboo wrote:
> I don't like that argument because there are many other things that can
> get out of sync when there is no connection (and indeed are far more
> likely). In particular, if you are offline and the organizer changes the
> time or location of an event, then you are in just as much trouble as
> you would be if the time zone changed and you did not know about it. I
> would postulate the former type of change is a lot more frequent than
> the later.

The key here from the point of view of tzdist is that the organiser may
not yet know that something has changed. They will pick that change up
at some point and deal with it, but in the interim the fact that their
published calendar is out of date would be flagged by the information
that it has used x and we now have x+1. That is the race condition I'd
like to see covered as it's the one that has caused problems in the past.

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Dec 2014 10:25:31 -0700

On 12/16/2014 09:51 AM, Lester Caine wrote:
> ...If you are only looking at current data then you only need the 
> current offsets. In ten years time if you have a set of material 
> archived today using the current version then you need access to that 
> old version. Since one may well be on a new computer by then we need a 
> means of accessing the data. Relying on the OS having already loaded 
> the history would be nice, but being able to get it as part of a TZ 
> distribution service somehow seems the right thing to be doing?... 

Version or old data (history)?

If you get the entire VTIMEZONE object, you have the historical values 
at any time the VTIMEZONE was defined. VTIMEZONE components may contain 
multiple DAYLIGHT/STANDARD components each with a unique DTSTART value 
that is valid until the next one with a newer DTSTART value.

If for some reason a there is a change in the historical data (typo, 
whatever) and there is an update to historical data, then the 
LAST-MODIFIED value in the VTIMEZONE would have been updated, get the 
entire object again or use the tzdist truncate method. I can't see a 
need for old errors. Maybe others will need it?

As I understand it 'version' can be any change, old data, new data. Just 
a way to tell the VTIMEZONE object changed for whatever reason.

I have not really given any thought to getting old error filled data.

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Dec 2014 11:02:03 -0700

On 12/16/2014 09:43 AM, Cyrus Daboo wrote:
> I don't like that argument because there are many other things that 
> can get out of sync when there is no connection (and indeed are far 
> more likely). In particular, if you are offline and the organizer 
> changes the time or location of an event, then you are in just as much 
> trouble as you would be if the time zone changed and you did not know 
> about it. I would postulate the former type of change is a lot more 
> frequent than the later.
>

Schedule changes are already detectable (iTIP SEQUENCE/DTSTAMP in new 
REQUEST or DTSTAMP for PUBLISH).

If a schedule change is made only because the organizer/CUA sees a TZ 
update and re-publishes the event, without some last-modified or version 
to the TZID, there would be no way for an attendee/CUA to know that it 
was because the TZ was updated. The only solution would be for the 
attendee/CUA to poll the tzdist-service for every change REQUEST, 
PUBLISH, or DTSTAMP change on a statically loaded event and that is not 
acceptable. The amount of tzdist-service polling would go up 
astronomically, or they would do as they do now, ignore TZ changes.

--

---

From: Lester Caine <[email-masked]>
Date: Tue, 16 Dec 2014 18:12:25 +0000

> Version or old data (history)?

We do have fun when documenting 'history of history'. That a TZid data
set contains the history and predicted future events is one element.
What we are managing with 'version' is the amendments to the data set,
be that improvement to the historic element, or amendment to the
forthcoming. That a particular version of the data has been used for a
particular set of material simply requires that the same TZid data set
will be required later to correctly view it, and possibly then update
the archive to a more current version. An archive of meetings should

> I have not really given any thought to getting old error filled data.

THAT is the important bit here. And the 'error filled' data may well be
due to a change in the future DST offsets as to historic changes due to
improved historic data. There is the problem of errors due to the lack
of 'backzone' data in some TZ sources but that is just a matter of the
right publisher rather than version, so both elements need to be
recorded once one is working on material like genealogical data. It's
trying to get to a point where one can use material and know that the
underlying time base is auditable that is important here. Even if it's
incorrect, one can review it using the matching TZ data.