Subject: [Tzdist] Reality check ...

From: Lester Caine <[email-masked]>
Date: Sat, 27 Sep 2014 14:57:30 +0100

While the existing charter has a somewhat limited target, there does
still seem to be some confusion over just what is on and off topic.

"By allowing clients and servers to use time zones "by reference"
significant network bandwidth and storage savings can be achieved."

The problem seems to be just how we define a reference?

My own history goes back beyond the point that Derick brought tz data
into PHP, but because of the different policies on the distributions,
there is no guarantee on just what version of TZ data is used, and no
way to reference that against anything practical. Add windows to the
equation, and the diversity of data grows. Even where all 'providers'
claim to be working from TZ, there can be variations not helped by the
current confusion there.

Simply adding a namespace to the equation to group references to
identify the particular source only goes half way to identifying what
data was originally being accessed by that reference. We do need to know
just which version of base data was being provided. That can NOT be
provided by the caching and automatic updating currently planned in tzdist.

Cyrus commented "in the case of iCalendar a frequent request will be to
look up a TZID the client got from some external source that could be
from any publisher" but that very statement assumes that the TZID
actually identifies the correct set of data? It would be nice if the
TZID DID reliably identify the data being used. If a lookup for a simple
TZID can return several different sets of data which one do you use?
That iCalendar would have to use the prefix simply ensures that it's
content actually matches the state of the data when that entry was created.

Simply assuming 'for the time being' that the data relating to a
'reference' is static and invariant is not a safe assumption, and while
a static server may be able to reliably pass updates to it's clients it
will not work for 'some external source' which is using a different view
of the data for that reference.

It is a fact that a large number of TZID entries are unlikely to change
since a common time was accepted for them. There may be a level of
uncertainty about the date of that event, so truncating to 1970 removes
the majority of that, but we still need some means of providing a
reference to the prior historic data which is outside the scope of the
TZ database.

-- 
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