Subject: Re: [Tzdist] Ticket #22

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Oct 2014 22:45:20 +0200

Dear friends and Colleague,

I would like to collect the opinion if ETag and changedsince are sufficient
for synchronization with the v2 description of  time zone closes removal.
If so, this issue # 22 [1] could be closed, otherwise, feel free to propose
some text.

[1] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/22

BR,
Daniel

On Fri, Sep 26, 2014 at 2:47 PM, Tobias Conradi <[email-masked]>
wrote:

> On Fri, Sep 26, 2014 at 11:27 AM, Daniel Migault <[email-masked]>
> wrote:
> >
> > On Fri, Sep 26, 2014 at 11:00 AM, Paul Eggert <[email-masked]>
> wrote:
> >>
> >> Daniel Migault wrote:
> >>>
> >>> The text for [Issue#16] and [Issue#18] seems to have reached
> consensus. I
> >>> propose to close [Issue#22] as it is addressed by [Issue#16] and
> >>> [Issue#18]and close [Issue#16] and [Issue#18] when the text will be
> >>> published in version 02.
> >>
> >>
> >> I'm afraid I am having trouble understanding this suggestion, since I
> >> don't know what "[Issue#18]" stands for.  (It'd be helpful if questions
> like
> >> the above came with URLs that people could read in order to figure out
> what
> >> is intended.)
> >>
> > I apology, here are the links:
> >     - [Issue#18] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18
> >     - [Issue#22] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/22
> >
> >> Anyway, as I recall some people felt that a publisher or server should
> >> never withdraw a name, whereas others felt that withdrawn names were a
> >> common practice and it's not tzdist's job to prohibit it.  Did we ever
> reach
> >> a consensus on that?
> >
> >
> > My understanding is that we reached consensus on the following text that
> > warns publishers of consequences from removing a zone [Issue#18]
> > http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18. tzdist at least
> > discourage such practice but  does not prohibit them.
> >
> > """
> >  If a time zone X is deleted, it is common for a publisher to make its
> >  identifier an alias for some other time zone Y, to cater to clients
> >  that may still be using X's identifier; because this changes Y, it can
> >  be discovered by a "list" with "changedsince".  In contrast, the
> >  outright deletion of X (with no other change) requires a "list"
> >  without "changedsince" to be discovered.
> >
> >  It is common for clients to silently substitute UTC for withdrawn or
> >  unknown time zone names.
> > """
>
> Your understanding is wrong.
>
> withdrawn time zone names? What are time zone names to begin with?
>
> The glossary says, a time zone is
> "A description of the historical and predicted timekeeping
> practices of a collection of clocks that are intended to agree;"
>
> Where is the evidence that
> - several publishers exist that define a time zone in that manner?
> - among those publishers several delete time zones
> - among the latter it is common to use the identifier of the deleted
> as an alias for another time zone
>
> ' /because this changes Y/, it can be discovered by a "list" with
> "changedsince" '
>
> From http://tools.ietf.org/id/draft-ietf-tzdist-service-01.txt
> ' If the "changedsince" query parameter is present its value MUST
>       correspond to a previously returned timestamp value. '
>
> Which "previously returned timestamp value" shall the user of X use here?
>
> And why is it suggested to use a "list" action, if all the user of X
> cares about is one time zone?
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>

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

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 22:45:45 +0100

On 23/10/14 21:45, Daniel Migault wrote:
> I would like to collect the opinion if ETag and changedsince are
> sufficient for synchronization with the v2 description of  time zone
> closes removal. If so, this issue # 22 [1] could be closed, otherwise,
> feel free to propose some text.
> 

In the context of ticket 22, the situation that I do not believe has yet
been addressed is where a user is moving between tzdist servers. While
the automatic caching of data with the addition of changedsince will
work while a user is using a single source, if a mobile device is moving
around the world, can it reliably maintain a connection to a single
source? This is why I would prefer to see a means of ensuring that when
accessing an alternate tz server one can gain access to a known state of
data. The version that the device was using originally.

The 'text' you are asking for is a reworking of the fallback which we
are currently discussing in relation to historic version access, but
equally applies to resynchronising a client in the case of a change of
server. I client needs to be able to obtain a matching version of data
from the new server in order to use changedsince safely.

-- 
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: Tobias Conradi <[email-masked]>
Date: Fri, 24 Oct 2014 03:10:32 +0200

On Thu, Oct 23, 2014 at 10:45 PM, Daniel Migault <[email-masked]> wrote:
> for synchronization with the v2 description of  time zone closes removal. If
> so, this issue # 22 [1] could be closed, otherwise, feel free to propose
> some text.
>
Ticket #22 doesn't mention ETag.

In
http://tools.ietf.org/html/draft-ietf-tzdist-service-02
I found six occurrences of ETag, but I found no policy on how to
generate it. Is there a policy?

If no such policy exists, then, for the purpose of TZDIST it can be
considered random. If it is random, then it is not a reliable
indicator for need of synchronization.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Oct 2014 21:22:59 -0400

Hi Tobias,

> indicator for need of synchronization.

For ETag please read <http://tools.ietf.org/html/rfc7232> which explains 
the use of that in HTTP. I will add a better reference in the tzdist draft 
for that. I can also add additional text on the use of ETag to the 
"Conditional Time Zone Requests" section.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 24 Oct 2014 04:09:07 +0200

On Fri, Oct 24, 2014 at 3:22 AM, Cyrus Daboo <[email-masked]> wrote:

> For ETag please read <http://tools.ietf.org/html/rfc7232> which explains the
> use of that in HTTP.
I read
http://tools.ietf.org/html/rfc7232#section-2.3.1
before. It says

"The principle behind entity-tags is that only the service author
   knows the implementation of a resource well enough to select the most
   accurate and efficient validation mechanism for that resource"

I found no string "service author" in
http://tools.ietf.org/html/draft-ietf-tzdist-service-02

Would that be Daboo? Would that be the person running a TZD server? If
the latter, then there can be multiple for the same set of time zone
data. But then, why does only the individual author knows "well
enough"?

> I will add a better reference in the tzdist draft for
> that. I can also add additional text on the use of ETag to the "Conditional
> Time Zone Requests" section.
That section
http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-4.1.3
is hard too read. "Time zone data is generally slow moving" - what is
slow? What is moving of time zone data? What is generally?

"during the course of a year being relatively small" - I assume during
the course of month, week or day even smaller? And in a decade bigger?

Why "during course" - does that mean there could be many changes at
the changeover from one year to the next?

What would be the difference to "during a year" and dropping "slow moving"?

How about
OLD
Time zone data is generally slow moving, with the set of time zones
   that change during the course of a year being relatively small.
   However, any changes that do occur, need to be distributed in a
   timely manner.

NEW
Any changes to time zone data that do occur, need to be distributed in
a timely manner. However, for time zone data sets that cover the whole
earth on each occurrence of such a change only less than x% of time
zone data is changed.

That means, start with what is needed (timely manner), and then say
when a re-download of all data is not efficient. Whether there are
many 3000 changes in a year or 10 (slow moving?) is irrelevant.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Fri, 24 Oct 2014 08:36:30 +0100

On 24/10/14 02:22, Cyrus Daboo wrote:
> the use of that in HTTP. I will add a better reference in the tzdist
> draft for that. I can also add additional text on the use of ETag to the

Tobias is still picking up on linguistic semantics which is probably how
it should be done, but I'm still looking at the practical application.
The whole point of an ETag is to provide an identification that the
'data' being accessed has not changed since one last asked.
( waffle cut ... I did work through a full flow but it's not relevant )

Of cause where this works reliably is where several thousand devices are
asking the same question, and the server can retain the last calculation
for a period of time. Actually it's that SOME materiel has to be
calculated here that is the problem? It's not necessarily 'static' since
the range of the subset requested may change daily? Serving a particular
historic view of a data set is never going to change, and so if the
transmission path already has a cached copy we can safely use that. HOW
the cached ETag is generated is not relevant for a fixed single
connection, but it may be useful if the data source is no longer
available and a secondary source can then continue providing the same data?

Practically, I would envision that a server will cache every data
request and when a change to published data is made available, every
cached copy that HAS changed can get reset. To my simple mind it makes
sense that the ETag IS defined and carries the source id and version
number of the underlying data so that it provides a security check that
what was asked for is what was supplied what ever the eventual source.
Although if the rules are set by the data source?

AGAIN this comes back to something which is out of scope, but so
important to get right from day one, management of the data :( We do
need to lay down at least a framework on which the fine detail can be
hung, and applying a few basic rules are not out of place here.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 24 Oct 2014 15:49:59 -0400

Hi Tobias,
(I will address the rewording part of your message in a separate message)

> data. But then, why does only the individual author knows "well

"service author" in 7232 refers to the developer of the application that is 
using HTTP. It is not something that a protocol using HTTP has to define. 
Note I could not find the term "service author" formally defined in the 
HTTPbis documents but I am sure others can confirm my interpretation.

As far as the implementation goes, the server is free to do whatever it 
likes for generating ETags so long as the expected semantics are as per the 
spec - i.e., it changes only when the underlying data changes. In my 
implementation the etag is simply a hash of the underlying time zone data.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 24 Oct 2014 16:04:13 -0400

Hi Tobias,

> slow? What is moving of time zone data? What is generally?

...

> many 3000 changes in a year or 10 (slow moving?) is irrelevant.

OK, taking your suggestion, here is what I propose:

OLD:

   Time zone data is generally slow moving, with the set of time zones
   that change during the course of a year being relatively small.
   However, any changes that do occur, need to be distributed in a
   timely manner.  Typically it is more efficient to just provide the
   set of changes to time zone data, so a client can do updates to any
   locally cached data.

New:

    When time zone data changes, it needs to be distributed in a timely
    manner because changes to local time offsets might occur within a few
    days of the publication of the time zone data changes. Typically, the
    number of time zones that change is small, whilst the overall number of
    time zones can be large. Thus it is more efficient for the client to be
    able to download only those time zones that have changed and which it
    needs.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 25 Oct 2014 00:14:16 +0200

> (I will address the rewording part of your message in a separate message)
Thanks for splitting and creating an email that has a subject
containing "ETags".

> implementation the etag is simply a hash of the underlying time zone data.
As mentioned at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00279.html
it could be of help to normalize the data.

Also what file-related ETags don't do is matching between sets of data
that come in different formats.

A format-independent hash tag that can also be presented in lists of
time zones might help.

I would downgrade ETag from "must" to "can" or at least to "should".
The capabilities-action could list what the server actually does. Why
should a server only because it does not generate ETags not be a
TZDIST server? Maybe there are situations where operation is more
efficient without ETags.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sat, 25 Oct 2014 00:30:38 +0100

>    able to download only those time zones that have changed and which it

+1
In reality even the historic variations probably affect less than 1% of
data based on the small numbers of changes from version to version, but
it is the use of the correct data that is important.

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 25 Oct 2014 04:24:27 +0200

On Fri, Oct 24, 2014 at 10:04 PM, Cyrus Daboo <[email-masked]> wrote:

>    days of the publication of the time zone data changes.
Actually this is only true for time zone data changes that affect
future time stamps, correct?

I hadn't addressed that part in my proposal neither.

> Typically, the
>    time zones can be large.

"However, for time zone data sets that cover the whole
earth on each occurrence of such a change only less than x% of time
zone data is changed."

is more precise. "Typically" is vague, as are "small" and "large". I
referred to the whole earth, because there could be a server hosting
only Russian time zones and they have been altered in the last years
all by one law or decree per date of change. So the "overall number of
time zones" = "number of time zones that change".

There could be more country specific TZDIST servers than TZDIST
servers that deliver data for the whole world, then the phrase
starting with "Typically" might be wrong.

> Thus it is more efficient for the client to be
There are use cases where this is true. But the justification is not
solid. And for servers only hosting data for one zone, it is wrong.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sat, 25 Oct 2014 08:54:21 +0100

> time zones" = "number of time zones that change".

That the entire set of visible data has be affected is not a typical
event and in the absence of anything that can be used to produce more
accurate figures, "Typical" is the correct term. If a server IS only
servicing a single ID, then it will be easy to identify those for which
there are any changes to offset during the year, and those that are
highly unlikely to ever change their offset in the foreseeable future.
Just as we can not dictate that politicians or more natural events will
provide a suitable lead time to allow for announcing a change, we can
only ever be vague about what may happen in the future.

Filling in the gaps going backwards is a similar vague process. While
new material may be deliberately suppressed to make the number of
identifiers manageable, we can not provide a documented set of rules as
to what will be found as the last year has demonstrated.

Hopefully at some point in the future, in a typical year there will be
no changes to the rules as  the nature of the rules improves, but some
how I doubt that since human beings are involved.

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 25 Oct 2014 17:10:40 +0200

On Sat, Oct 25, 2014 at 9:54 AM, Lester Caine <[email-masked]> wrote:
> event
Once more a new term, What do you refer to by "visible data"?`

What is the source of your claim?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 25 Oct 2014 13:37:10 -0400

Hi Tobias,

> future time stamps, correct?

Yes - which is what is implied.

>> Typically, the
>>    number of time zones that change is small, whilst the overall number
>>    of time zones can be large.
>

This text is not meant to be "precise" about all the different ways time 
zones can change and what is expected to happen. Its sole purpose is to 
justify the need for the "changedsince" feature in the protocol. Therefore 
I don't want to have to go analyze all the historical changes to tz data to 
figure out what x% changed each time.

> solid. And for servers only hosting data for one zone, it is wrong.

Again, the purpose is to justify why "changedsince" is needed - not explain 
all possible configurations and use cases of servers and clients.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 26 Oct 2014 16:25:29 +0100

> Yes - which is what is implied.
It is not. I cannot be derived from the text. The text says "When time
zone data changes, it needs... ".

If it is not true for all cases covered by "When time zone data
changes", then the statement is false.

I propose not to knowingly add false statements to the spec.

> zones can change and what is expected to happen.
I didn't propose that.

> Its sole purpose is to
> justify the need for the "changedsince" feature in the protocol.
A false statement does not justify it.

> Therefore I
> don't want to have to go analyze all the historical changes to tz data to
You must have had some idea about x since you wrote

"the number of time zones that change is small". You could put x at 50
to begin with.

> all possible configurations and use cases of servers and clients.

The above false statement, not any other false statement is not a
justification for changedsince, because a reader can say: "not true".

A false statement does not fulfill the purpose.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 26 Oct 2014 16:29:49 +0100

I didn't talk of visible.

I said the server could only host data for a part of the world.

It could also be that there is a database that only cares about a part
of the world. That means, all data of that source could be hosted and
still it would fit with my example.

On Sat, Oct 25, 2014 at 6:14 PM, Lester Caine <[email-masked]> wrote:
> You specified the amount of data visible was reduced to just one area which
> is a perfectly viable senario, but even an unpredicted change here is not
> typical ....
>
> Sent from my android device so the quoting is crap!
>
>
> -----Original Message-----
> From: Tobias Conradi <[email-masked]>
> To: Lester Caine <[email-masked]>
> Cc: Time Zone Data Distribution Service <[email-masked]>
> Sent: Sat, 25 Oct 2014 4:10 PM
> Subject: Re: [Tzdist] Ticket #22
>

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 26 Oct 2014 11:35:49 -0400

Hi Tobias,

--On October 26, 2014 at 4:25:29 PM +0100 Tobias Conradi 
<[email-masked]> wrote:

>> Again, the purpose is to justify why "changedsince" is needed - not
>> explain all possible configurations and use cases of servers and clients.
>

Sorry - end of thread. I wrote that text to justify "changedsince" hence it 
is not false unless you are saying I am trying to sabotage this 
specification. Unless anyone else objects, my original proposed text stands.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Sun, 26 Oct 2014 16:24:55 +0000

> still it would fit with my example.

So only a subset of data is visible to their users ....

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 26 Oct 2014 17:37:34 +0100

> So only a subset of data is visible to their users ....
No, all data from that database. No subset.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Sun, 26 Oct 2014 17:43:22 +0100

On Sun, Oct 26, 2014 at 4:35 PM, Cyrus Daboo <[email-masked]> wrote:
> Sorry - end of thread. I wrote that text to justify "changedsince"
But it does not.

> hence it
> specification.
I didn't claim you try. I only said that false statements cannot
justify "changedsince".

A chain of logical statements is interrupted by any false statement,
and everything that follows in the text and was intended to be
justified by that chain, is not.

What is the sense of knowingly introducing a false statement?

> Unless anyone else objects, my original proposed text stands.
So, logic is not the way to go for you? Your way is majority voting instead?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Mon, 27 Oct 2014 10:13:58 +0000

> explain all possible configurations and use cases of servers and clients.

OK Time to post this to the list. I'd copied Cyrus yesterday for some
input on iCalendar but I'm not sure he received it
I was taking advantage of the extra hour to catch up yesterday morning
( and the Dogs will take a few days to realise they are being feed an
hour later ... :) )

This is the crux to my own 'problem' with all of this
I have tz2014h on the system ... 'latest' tells me it's tz2014i so ALL I
need is the difference between 'h' and 'i' - and to keep Tobias happy
that may well be an empty data set if he is only interested in a subset
of data.

The following is not the current diff on those versions, but just an
example.
Currently I ask for the 'changedsince' list and it gives me all the
TZID's which have changed, but if you go back to the source, perhaps
just one modern generic rule has a change say Central European Time for
example. If I have several dozen city related rules it will list all of
them since each has to be expanded with the new element. The States is
probably another example of several hundred potential TZID's which may
be affected by just one current generic change?

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. All of the historic material can
then be managed separately and does not need to be retransmitted every time.

An example of how to get this badly wrong is provided by geonames which
produces nightly updates to it's cross reference which includes the
current TZ id ( thankfully still including the pre 1970 list of ID's )
but it ONLY publishes the whole database plus ONE last issue. So if you
miss a night ... back to square one. At least with the openstreetmap
data one can get the incremental versions you have missed and can filter
a download on just TZ data. But at some point a service can be set up to
maintain just the TZID element of geonames along with an historic track
for the history of a locations change of TZID. THIS could quite easily
provide all of the pre-1970 material to completely map the sequence for
a location, something which the TZ data is not 'chartered' to provide
pre-1970. Linked with OSM one has the geographic mapping as well.

tzdist is filling a small cog in a much bigger engine which is in
desperate need of fixing. For international websites we NEED that the
current useless 'tzoffset' is replaced with a valid and universally
recognised TZID and I accept that this may need to be an id that is only
correct for the recent past going forward so long as asking for data (
time rules or 'expanded' conversions ) prior to the sources capability
it is flagged as such from day one. But it is worth noting that the TZID
returned will be that provided by the clients browser and not a
particular tzdist source which IS why some standardisation of that
element is important in the bigger picture.

Does this make sense? Does it explain why I feel the basic process is
not quite right and does not scale well when the whole range of historic
data is added? I think if the iCalendar rules have a valid start date
and use the generic TZ rule ID's, then the current draft works. All that
is missing is that 'aliases' may become rules linking the much smaller
set of currently active rules with the more static historic data.

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 27 Oct 2014 13:17:57 +0100

On Mon, Oct 27, 2014 at 11:13 AM, Lester Caine <[email-masked]> wrote:

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

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Oct 2014 10:04:50 -0400

Hi Tobias,

> So, logic is not the way to go for you? Your way is majority voting

We don't need to debate that - the way we operate is the IETF way - and 
there is plenty of documentation available as to what that is.

My currently plan is to publish a new version of the draft later this week. 
In that I will beef up the section "Conditional Time Zone Requests" section 
using the text I previously sent (with some clarifications that it refers 
to the "changedseince" behavior designed into the protocol) together with 
additional text regarding the use of ETags (as mentioned in a different 
thread).

I am going to get other minor changes, clarifications, re-organizations 
done too. The issue of changing the URL design is still open for design, so 
I won't address that in the next draft.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 27 Oct 2014 10:18:06 -0400

Hi Lester,

> set of currently active rules with the more static historic data.

I think the crus of the problem here is the different data models exposed 
by the IANA/Olson data vs iCalendar.

The IANA/Olson model (at a very basic level) defines a set of "Rules" and a 
set of "Zones", where each "Zone" is made up of one or more sets of 
different "Rules". So, as you point out, several "Zones" can make use of 
the same basic "Rules" even though they represent different overall 
offsets. So "zones" include "rules" by reference.

The iCalendar model is one that simply describes the set of transitions for 
a single "Zone", and thus the "rules" are included by value (rather than by 
reference). This is basically the same model as the zoneinfo data used by 
Unix systems. I am not too familiar with Windows, but I suspect it is the 
same.

As mentioned on the call, I think if the "historic" data is needed - or 
more specifically if access to the underlying IANA/Olson model is needed - 
that could be accomplished by defining a new media type and standard data 
format for that. I believe the current tzdist protocol has sufficient 
extensibility to support - including the potential separation of zones and 
rules, so that changes to rules don't have to result in changes to the 
actual zone data (which includes them only by reference).

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Mon, 27 Oct 2014 14:43:13 +0000

On 27/10/14 14:18, Cyrus Daboo wrote:
> I believe the current tzdist protocol has sufficient extensibility to
> support - including the potential separation of zones and rules, so that
> changes to rules don't have to result in changes to the actual zone data
> (which includes them only by reference).

By picking the best truncation point, a current set of data could match
the current base rules. since large areas of the world are now all
following a much smaller data set. The problem that arises is when a
client device needs access to the several dozen sets of data that
pre-date that cutoff. We have a problem making things contiguous.
iCalandar will expect a full expansion of data for each ID? There is no
way to say 'use x until' then 'use y'. The same problem has been created
in the raw TZ data since the default published data omits historic data
that only changes prior to 1970. How does a user know that the data they
are accessing is perhaps not valid for that earlier period where TZ is
publishing the later generic rule? The 'TZSTART' value is only valid for
that rule set, not the necessarily the associated aliases?

I just feel that since the source material is outside of the scope of
the draft there is a risk that what is used initially will not clearly
identify what is true valid data and what is assumption because the
current rule sets match. I'm unsure that valid text can be added to the
draft to cover this area since it is out of scope?

---

From: Lester Caine <[email-masked]>
Date: Tue, 28 Oct 2014 06:52:56 +0000

> Russia, and named zones like Eastern Time, Mountain Time etc in the

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.