Subject: [Tzdist] Scope of the discussions

From: Daniel Migault <[email-masked]>
Date: Sun, 24 Aug 2014 10:05:49 +0200

Dear friends and colleagues,

Discussions are quite active and are helpful to make progress. However,
before we got to much out of scope of the charter, we would like to raise
some clarifications on our charter.

The charter explicitly mention that TZ Database format as out of scope. So,
-- although of interest--, I would consider, discussions of leap seconds or
time before some period of time immaterial to our purpose.

The goal of this WG to to come out with a deployable Time Zone distribution
protocol that is viable with the current Time Zone Data Base and
*extensible* for future format or options.

Time Zone Database may be considered when re-chartering... and that would
be a huge ambitious and interesting item ;-)

Daniel and Eliot
-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Sun, 24 Aug 2014 10:43:15 +0100

On 24/08/14 09:05, Daniel Migault wrote:
> The charter explicitly mention that TZ Database format as out of scope.
> So, -- although of interest--, I would consider, discussions of leap
> seconds or time before some period of time immaterial to our purpose.
> 
> The goal of this WG to to come out with a deployable Time Zone
> distribution protocol that is viable with the current Time Zone Data
> Base and *extensible* for future format or options.
> 
> Time Zone Database may be considered when re-chartering... and that
> would be a huge ambitious and interesting item ;-)

I still see the problem here that while the 'TZ Database format' may be
out of scope, the content of that data how ever it is maintained is the
material which the tzdist protocol has to distribute? From my own
standpoint, I'm not worried about the fine detail of how many seconds in
a day and my own method of working separates those problems with time
being a fraction of a day rather than what I've always viewed as silly -
a count of seconds. Since the whole mechanism IS designed around a
seconds based versioning system the starting point has to be just which
clock is used for that, but for historic records seconds accuracy is not
something that can be relied on and until radio linked clocks appeared I
think we can avoid worrying if it was 'just after noon' or 'just after
noon and 10 seconds' :) It WOULD however be useful if we could identify
if a timezone was based on the Greenwich or Paris Meridian as it was not
until 1911 that French and British Times aligned? Alright it was only a
30 or so year period when there was a slow coming together under what we
see today as the 'standard' and I feel that the 'charter' is perhaps
somewhat remiss in not ACTUALLY identifying just what level of data will
be supported? Just as the tz database is still trying to restrict it's
'charter' in only supporting post 1970 data in which case we need an
alternative!

While the standards may be *extensible*, the information being recorded
and normalized today has to be usable in years to come. Alright all
historic data may need to be reviewed if there is a drastic change to
the system, but if I've normalized millions of records today and tagged
them with the current 'dtstamp' is it my responsibility to maintain a
service that will return the correct 'changedsince' data in 10 years
time? We have had responses that this is not what the mechanism is
designed for? But it is fundamental to ANY tzdist system?

My own prompt to get this right was when Council meetings I was serving
up on a third party system suddenly moved an hour! Yes, the mechanism
for handling DST had bugs in it and took a while to sort out, but the
result is all data is NOW stored UTC normalised and served up with the
relevant local display. The data goes back over 20 years now and there
is already a plan to include earlier archive data - pre1970! - into the
database. However the problem that has not yet been solved is that
meetings are being arranged 2 or 3 years ahead, and we know if there is
a change to DST then we will have to manually check the affected
meetings. THIS is a critical action that tzdist must support cleanly and
reliably? The internal storage method for this data is an integral part
of making any system work, and simply saying 'it's not our problem' just
does not fit with making any system work?

-- 
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: Eliot Lear <[email-masked]>
Date: Sun, 24 Aug 2014 12:28:55 +0200

Hi Lester,

On 8/24/14, 11:43 AM, Lester Caine wrote:
> material which the tzdist protocol has to distribute?

The best analogy I can think of is NNTP, which was a bit like a fancy
file transfer system that was optimized for the content.  To this end we
should limit discussion of content to what names there are to chose from
(e.g., list), how much data to return, including how to handle small
differences in understanding of UTC, perhaps due to issues surrounding
leap seconds (such as allowing a server to respond with one additional
entry beyond what the client requested), and indication of the format of
the rest of the response that contains the TZ data.  And that's about it.

>  From my own

But I don't see this as something to be done in a timezone distribution
protocol.  That is an issue for the various TZ databases.  Please take
it to them.
> designed for? But it is fundamental to ANY tzdist system?

The stability of the database is a matter for the database maintainer
and associated groups.  Again, this is JUST a protocol that moves bits.

Make sense?

Eliot

---

From: Lester Caine <[email-masked]>
Date: Sun, 24 Aug 2014 12:45:25 +0100

> and associated groups.  Again, this is JUST a protocol that moves bits.

Yes and no ...
'JUST a protocol that moves bits' is not a lot of use if no one agrees
on the 'bits' it is moving, and that is my argument here. The current
subset of fields in the iCalendar timebase package already restricts
it's usefulness in relaying historic data, and that includes DST changes
going forward. OK things can be extended by third party users and
additional standards can be defined, and perhaps that is what we have to
live with. The charter has no requirement to produce a standard we can
rely on? So there is no need to bother? Just produce something that
fills the charter points?

That the protocol is 'initially be targeted at iCalendar-based clients'
is already a restriction on just how flexible and 'standard' the service
will be. Again it has already been indicated that some people are
looking to provide additional fields to the cover the version timestamp,
but I can see a requirement for something a lot more flexible for
cloning the underlying data between mirror servers. The main problem
here is fundamental to a working system and it IS the management of
versions. If the server that provided the original data has gone down,
and a backup is used, can the 'dtstamp' even be relied on as part of the
'changedsince' process? This is even more fundamental to modern data
than historic material as a change of DST data at short notice needs to
be reliable. Has any consideration been given to using different tzdist
servers as access allows? This is where the provenance of the underlying
data is critical to providing a clean rollout of a change which can
generally be relied on?

---

From: Eliot Lear <[email-masked]>
Date: Sun, 24 Aug 2014 18:11:09 +0200

> fills the charter points?

Different TZ databases are going to have different characteristics.  One
wants to make the tzdist standard as generally applicable as is
practicable, and also we don't want to boil the ocean.

And so as to your example:
> will be.

I find that not only acceptable but necessary, so as to make the task
achievable.

>  Again it has already been indicated that some people are
> cloning the underlying data between mirror servers.

If the working group finds it necessary, ok.  BUT: let's not make the
cure worse than the disease.  If the "flexibility" requires very complex
implementations, we'll need to back off.  The best way to prove that
this is not the case would be to demonstrate running code.

>  The main problem
> 'changedsince' process?

I'll ask Cyrus or Mike to correct me on this, but my presumption is that
the provider will need to sort that if the publisher doesn't provide the
information, under the model in draft-douglass-timezone-service.

>  This is even more fundamental to modern data

That will greatly depend on the provider.

Eliot