Subject: Re: [Tzdist] Ticket #22

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Nov 2014 12:52:48 +0100

Dear friends and Colleagues,

We are asking the WG whether Issue #22
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/22> "a short notice
change will affect current meeting time" has been addressed by
draft-ietf-tzdist-service-03
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03>. Feel free to
give your opinion by Friday 21, so we can cleanup the open issue and focus
our attention on issues that have not been solved yet.

BR,
Danieland Eliot

On Tue, Oct 28, 2014 at 7:52 AM, Lester Caine <[email-masked]> wrote:

> On 27/10/14 12:17, Tobias Conradi wrote:
> >> Now if the ZTIMEZONE format could handle 'nesting' ... which is
> >> > essentaially what the raw TZ data does ... we could just send the CET
> >> > change and the client ( or slave server ) can pick up the change and
> >> > assess if it affects things locally.
> > Since June 2012 there is a proposal how zones like CET could get IDs
> >
> >
> http://anna.info/wiki/Internationalized_time_point_unique_time_zone_abbreviations
> >
> > In that case it would be EUCT
> > - EU - two-letter code for European Union and other things related to
> Europe.
> > - C - zone C in that area.
> > - T - Time, could be omitted.
> >
> > For Russia it could but RU1, RU2, RU3 ... as numbered in the latest
> > law. USA could be USET, USCT, USMT, USPT.
> >
> > That's also closer to the actual laws, which mention zone numbers in
> > Russia, and named zones like Eastern Time, Mountain Time etc in the
> > USA.
>
> This is usable for providing TZID identifiers for the current set of
> daylight saving rules but is not scalable to provide on unlimited range
> of id's to cover historic variations.
>
> It comes back to my earlier point that a set of rules is not a location
> but is simply an identifiable set of rules with a well defined start
> date. NOW that that concept has been added, there is no reason that ehis
> set of aliases can not be supported in parallel with any other naming
> convention. tzdist has no control over just what is used, which is still
> a problem in the bigger picture.
>
> --
> 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
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Lester Caine <[email-masked]>
Date: Tue, 18 Nov 2014 12:33:18 +0000

On 18/11/14 11:52, Daniel Migault wrote:
> give your opinion by Friday 21, so we can cleanup the open issue and
> focus our attention on issues that have not been solved yet.

I still see a fundamental race hazard with the basic process which is
carried out when a change is published which I've indicated is solved by
the use of a version number as part of the process, but is not fully
required in the current draft. Even if all the users who are affected by
the change are already synced to a single source of tz data, there is no
stable state in the distribution system, and when users may be using
different sources to the original data set the problem is increased.

There is still not mechanism in the draft to ensure that a user has the
right version of data to go with the calender data to which it is being
applied.