Subject: [Tzdist] Existing and new data ...

From: Lester Caine <[email-masked]>
Date: Wed, 10 Dec 2014 17:43:30 +0000

One thing that may not be obvious from my ranting is that we have two
different situations. Once a user has accessed a published TZ dataset,
then KEEPING it in sync is something that 'changedsince' can be relied
on, but I would anticipate that there will be more than one published
being cached locally.

The problem comes when one is syncing with the publisher for the first
time, and this is mainly where the race hazard exists. Both the
publisher and version are needed to ensure that the correct starting
point is established, but even if that publisher is already cached
locally, the local 'latest' may be later than that which was used a few
hours earlier by the new diary source one is looking at.

We are talking about a very narrow group of TZid's and very infrequent
events, but race conditions like these can't simply be brushed under the
carpet. Even today upcoming TZ data changes are being discussed and
these may well effect a diary of event published for next year. SInce
changedsince only has relevance once one HAS downloaded the data it
can't be used to sync with other published material, only version can
provide the safety of ensuring that the correct information and TZ data
are used ... even if that THEN flags that events may be incorrect due to
'latest' being a later version ... perhaps three or four versions ahead
for a half yearly diary.

-- 
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: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Dec 2014 12:58:05 -0500

Hi Lester,

> 'latest' being a later version ... perhaps three or four versions ahead

I have not come across a single client to date that will detect a change to 
time zone data and warn users about possible shifts to meeting times as a 
result of that. They simply can't figure that out as the underlying TZ data 
typically is coming from the OS and there is no version information readily 
available.

With tzdist, we have the option of including an extension for use with 
changedsince, whereby the server could tell the client exactly which time 
periods are impacted by a change to time zone data. But there is no point 
in implementing that in the base unless we know for sure clients will 
really use it. The first step here is to simply get them using the base 
protocol which should dramatically improve on the current state of affairs. 
Once we have that, more complicated pieces such as period change reporting, 
lookup via geo co-ordinates etc can be added.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 10 Dec 2014 18:35:28 +0000

On 10/12/14 17:58, Cyrus Daboo wrote:
> I have not come across a single client to date that will detect a change
> to time zone data and warn users about possible shifts to meeting times
> as a result of that. They simply can't figure that out as the underlying
> TZ data typically is coming from the OS and there is no version
> information readily available.

This is perhaps the point. The current mechanism is so badly broken we
can't even establish just where the source TZ material came from. THAT
is why I started digging since not only was historic material corrupted
due to the lack of tagging as to how it was created, but also current
data was being corrupted by using essentially broken versions of TZ data.

We need to CREATE a process that can be relied on to provide TZ data to
go with ANYTHING we publish from day one, and that requires a version.
That same version then allows client applications ... if they can be
bothered .. to check the integrity of what they are displaying. Perhaps
only certain clients will use the process, but a reliable process IS
necessary. This then simply expands over time to provide reliable
reference material for historic archives, and that may well be todays
calendars of events which while one might expect the data to be the same
in many years time, simply being able to access a perfectly matched
extract for the TZid and period of the material may be important if the
tzdist publisher is 'only' producing a truncated view for the then
current period.

My own rude awakening to this was when all the scheduled council
meetings moved an hour on the diary when the DST rolled over because the
person who had 'improved' the calendar code at that time did not even
understand what DST was :( Just because software gets it wrong is not a
reason for continuing to live with the problem?

---

From: Paul Eggert <[email-masked]>
Date: Wed, 10 Dec 2014 10:42:55 -0800

> go with ANYTHING we publish from day one, and that requires a version.

If data entries have versions, why do we need changedsince?  The two 
mechanisms seem duplicative.  If the two issues are orthogonal, this 
should be clearly explained in the draft.  And if not, perhaps the two 
issues should be unified.

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Dec 2014 11:54:09 -0700

Most (all?) implementations ignore time zone change pushes. Most calendar
users are clueless to TZ details and would not know if they changed and
would not do a manual push.

Most (all?) user agent implementations can not automatically detect or
start up after a TZ change in order to push the update.

-
Doug Royer
[email-masked]
(714)989-6135

On Wed, Dec 10, 2014 at 11:35 AM, Lester Caine <[email-masked]> wrote:

> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

---

From: Lester Caine <[email-masked]>
Date: Wed, 10 Dec 2014 19:04:32 +0000

On 10/12/14 18:54, Doug Royer wrote:
> Most (all?) implementations ignore time zone change pushes. Most
> calendar users are clueless to TZ details and would not know if they
> changed and would not do a manual push.
> 

Totally agree ... It is only in the last few years that live inter
continental events have become the norm and being able to reliably sync
things using UTC time has become important. What is being designed in
tzdist is a stable means of ensuring people ARE using the same data, but
it will be some time before all of the capability is fully exposited?

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Dec 2014 14:14:29 -0500

Hi Lester,

> it will be some time before all of the capability is fully exposited?

Right, but the tzdist protocol should not be telling clients what to do in 
the absence of tzdist. A separate document describing best practices for 
use of time zones (be they from tzdist or any other source) would be a 
better place for that.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Dec 2014 14:17:50 -0500

Hi Paul,

> issues should be unified.

"changedsince" allows the client to request a "diff" in the list action 
response - i.e., only get the list of time zones that have changed. If we 
adopted the IANA tzdb version numbering scheme, then every time a new 
version is released ALL time zones would be marked as "new" since their 
version number has changed, even though the actual time zone information 
(UTC offset, DST rules etc) is likely the same for the majority of them.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Wed, 10 Dec 2014 14:28:09 -0500

My own approach to this, server-side, is to store local-time, the 
calculated UTC and the tzid.

When I know the tz has changed in some way I can recalculate the UTC and 
see if I get a different result. If I do, the meeting MUST be 
rescheduled. It is not possible to autocorrect.

What matters to the end user is actually the local time - the UTC is 
what we use to ensure that 2 users with different local times are 
meeting at the same instant. When the rules change one of those users is 
going to have to change the local time of their meeting - that may 
result in a conflict - thus the need to reschedule.

I don't actually need a version - it won't help. I'd rather not do this 
process if the end result is that all the UTC times will come out the 
same. I'd like to have a tz distributions system that told me what 
timezones had changed (in a significant manner) since I last looked. 
Hopefully that set will be small. Knowing I have a new release of the tz 
data isn't very helpful. I want a lastmod that means something.

Even better, if I could be told what range of dates were affected I 
could then query my own data for possibly affected events and deal only 
with those.

I understand that there are some applications that are interested in 
knowing exactly which set of tz rules were used to calculate the offset 
- or at least the offset that was in effect at the time some incident 
occurred. I have had conversations with people involved with the power 
industry and we might remember the incident in which someone was accused 
of a threat because they made a call 1 hour later than the actual threat 
call.

However, the thing that affects most of us - and is a good starting 
point - is to try to ensure our calendars display the correct time for 
events. No version is needed - just an understanding that to the end 
user local time is what matters and that just storing UTC is insufficient.

And, yes, I understand that I could achieve something like the same 
result by storing a different triple involving versions but I need the 
UTC anyway.

---

From: Lester Caine <[email-masked]>
Date: Wed, 10 Dec 2014 19:28:22 +0000

On 10/12/14 19:14, Cyrus Daboo wrote:
> Right, but the tzdist protocol should not be telling clients what to do
> in the absence of tzdist. A separate document describing best practices
> for use of time zones (be they from tzdist or any other source) would be
> a better place for that.

? Don't understand that. When tzdist starts to distribute data then it's
data will be used as it is today. Unless you expect every user to update
their published content using tzdist every time there is a change, there
HAS to be a mechanism to access the data at the point in time the
material was published. I see nothing external to a system for
publishing TZ data as the core process.

The ramifications of published changes may benefit from a separate
document, but maintaining published data IS a core function.

---

From: Paul Eggert <[email-masked]>
Date: Wed, 10 Dec 2014 11:39:14 -0800

On 12/10/2014 11:17 AM, Cyrus Daboo wrote:
> "changedsince" allows the client to request a "diff" in the list 
> action response - i.e., only get the list of time zones that have 
> changed. If we adopted the IANA tzdb version numbering scheme, then 
> every time a new version is released ALL time zones would be marked as 
> "new" since their version number has changed, even though the actual 
> time zone information (UTC offset, DST rules etc) is likely the same 
> for the majority of them.

First, thanks for writing that -- something like that should be in the 
document, if we have versions.

Second, though, this doesn't explain why changedsince uses dates and not 
version numbers.  If a client is using tz2014a and the server says 
tz2014b is the latest, why can't the client say "I've got version 
tz2014a of America/Los_Angeles; is that good enough?".  The fact that a 
client can't ask this suggests that versions and changedsince are two 
different mechanisms for attacking the same problem, which complicates 
the protocol unnecessarily.  It'd be better to have just one mechanism here.

---

From: Matthew Bobowski <[email-masked]>
Date: Wed, 10 Dec 2014 14:48:28 -0500

I have to agree with Mr. Douglass. Another point is that calendar
scheduling is just one type of client usage. My interest for Timezone
Distribution Service is at the system level 1. for retrieval of timezones,
and 2. the ability to get updated information for timezone and DST
settings. Having a version complicates the issue here.

-Matt

On Wed, Dec 10, 2014 at 2:28 PM, Mike Douglass <[email-masked]>
wrote:

> see if I get a different result. If I do, the meeting MUST be rescheduled.
> It is not possible to autocorrect.
>
> What matters to the end user is actually the local time - the UTC is what
> we use to ensure that 2 users with different local times are meeting at the
> same instant. When the rules change one of those users is going to have to
> change the local time of their meeting - that may result in a conflict -
> thus the need to reschedule.
>
> process if the end result is that all the UTC times will come out the same.
> I'd like to have a tz distributions system that told me what timezones had
> changed (in a significant manner) since I last looked. Hopefully that set
> will be small. Knowing I have a new release of the tz data isn't very
> helpful. I want a lastmod that means something.
>
> Even better, if I could be told what range of dates were affected I could
> then query my own data for possibly affected events and deal only with
> those.
>
> knowing exactly which set of tz rules were used to calculate the offset -
> or at least the offset that was in effect at the time some incident
> industry and we might remember the incident in which someone was accused of
> a threat because they made a call 1 hour later than the actual threat call.
>
> However, the thing that affects most of us - and is a good starting point
> - is to try to ensure our calendars display the correct time for events. No
> version is needed - just an understanding that to the end user local time
> is what matters and that just storing UTC is insufficient.
>
> And, yes, I understand that I could achieve something like the same result
> by storing a different triple involving versions but I need the UTC anyway.
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 10 Dec 2014 15:13:45 -0500

Hi Paul,

--On December 10, 2014 at 11:39:14 AM -0800 Paul Eggert 
<[email-masked]> wrote:

> tz2014b is the latest, why can't the client say "I've got version tz2014a
> of America/Los_Angeles; is that good enough?".  The fact that a client
> can't ask this suggests that versions and changedsince are two different
> mechanisms for attacking the same problem, which complicates the protocol
> unnecessarily.  It'd be better to have just one mechanism here.

So if /zones were sourced from a single publisher then I could see that 
using an opaque token (the publisher version id) instead of 
dtstamp/changedsince would make sense. But if /zones is actually an 
aggregate of multiple publisher data - each with their own version ids - 
then that would be problematic.

One solution might be this:

- The /list response returns a JSON object that represents the 
publisher/version tuples for all the data returned by /zones.

- If the client just wants the diff, then it does a POST on /zones with a 
JSON request body containing the publisher/version tuples from the last 
/zones request it did. When the server sees that it does the list "diff" 
operation based on the publisher/version tuples and returns only those 
zones that are different across any changes in the versions. It would also 
return a new publisher/version tuple list for the client to use in its next 
request.

If we did that, I would suggest extending the list response to also "tag" 
each timezone with the publisher/version tuple information (only required 
when more than one publisher is in use).

Note that I still want /zones to represent the most recent version from 
each publisher - actually accessing older versions is left for the 
/versions URI mechanism.

If we do this, then the /list response metadata contains the information 
that Lester wants (and that I do not want in the actual time zone data 
returned by tzdist). Clients can use that as metadata to do more complex 
time zone synchronization checks if they want (but we won't specific 
exactly what that might be in tzdist itself).

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Wed, 10 Dec 2014 18:51:10 -0800

Cyrus Daboo wrote:
> So if /zones were sourced from a single publisher then I could see that using an
> opaque token (the publisher version id) instead of dtstamp/changedsince would
> make sense. But if /zones is actually an aggregate of multiple publisher data -
> each with their own version ids - then that would be problematic.

It's a problem easily solved.  A publisher who's compiling an aggregate should 
assign a version number to the aggregate.  That's what the tz database already 
does: it's an aggregate, after all.

This solves the problem without any need to change the protocol.  And it's easy 
to explain to publishers and to users.

---

From: Matthew Bobowski <[email-masked]>
Date: Wed, 10 Dec 2014 22:50:18 -0500

Why would a version number be needed at all? Could a controlled UTC
datestamp provide the same functionality? The datestamp would only need to
be updated when something significant happens.

On Wed, Dec 10, 2014 at 9:51 PM, Paul Eggert <[email-masked]> wrote:

>> using an
> It's a problem easily solved.  A publisher who's compiling an aggregate
> should assign a version number to the aggregate.  That's what the tz
> database already does: it's an aggregate, after all.
>
> This solves the problem without any need to change the protocol.  And it's
> easy to explain to publishers and to users.
>
>

---

From: Lester Caine <[email-masked]>
Date: Thu, 11 Dec 2014 09:05:54 +0000

On 11/12/14 03:50, Matthew Bobowski wrote:
> datestamp provide the same functionality? The datestamp would only need
> to be updated when something significant happens.

Currently tables of TZ data exist in many systems, and in some cases
even different tables within the one system. Material that was archived
many years ago is in a lot of cases now corrupt as the data used to
normalize that material has been lost ... we do not know the
publisher/type/version of that data. Today we have exactly the same
situation. Do you know just what version of TZ data you are currently
using and over what time range it is accurate?

My copy of TZ data may well be completely different to yours simply
because mine has pre-1970 material and yours does not. If I publish my
data on a genealogical web site for others to search and timeline and
they are using the truncated data then dates will be translated
differently. When you use that material you also need to know exactly
which version of the data set was used. TZ data only gets updated a few
times a year, is cleanly versioned, but even on the TZ list there is an
active debate on what material can be 'thrown away' (backzone) to make
things simple for current TZ users. The range of reliable data varies so
we need to know that fact and which type of truncation was used.

New genealogical data is being added daily, and that needs to be
correctly tagged with the 'current' version of TZ being used to create
it so that it will remain valid material. 'datestamp' is just a
different key for the version number ... it does not change the fact
that in the future SOME users need access to a view of the data as it
was created today in order to review the material they are looking at,
be that a 5 year old diary of council meetings or a hundred year old
list of events on a battle field.

Cyrus is of the opinion that changedsince is adequate to achieve a
reliable system. I can not see how that can be relied on to ensure
material published today is still reliable in the future.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Dec 2014 10:29:29 -0500

Hi Paul,

--On December 10, 2014 at 6:51:10 PM -0800 Paul Eggert <[email-masked]> 
wrote:

> This solves the problem without any need to change the protocol.  And
> it's easy to explain to publishers and to users.

I don't think that really deals with Lester's issue. If the tzdist server 
itself does the aggregation, then the version information is specific to 
that one server e.g., it aggregates from publishers A & B which each have 
version a1 and b1 respectively, and generates a "virtual" publisher 
(itself) S with version s1. Clients using that server see time zones tagged 
with publisher S and version s1, but if they include the version info in 
ther data they send to some other client using a different tzdist server 
then there is no easy way for that other client to correlate the 
publisher/version with the data their tzdist servers up (which may only be 
for publisher A).

So I do think we need to preserve the underlying publisher/version tuples 
at the service level. If someone does want to aggregate, then they become a 
"real" publisher in some fashion (this is leading towards the idea of 
registering publisher ids). But I don't think the service document needs to 
delve too deeply into that beyond preserving the underlying 
publisher/version ids.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Thu, 11 Dec 2014 16:03:46 +0000

On 11/12/14 15:29, Cyrus Daboo wrote:
> I don't think that really deals with Lester's issue. If the tzdist
> server itself does the aggregation, then the version information is
> specific to that one server e.g., it aggregates from publishers A & B
> which each have version a1 and b1 respectively, and generates a
> "virtual" publisher (itself) S with version s1. Clients using that
> server see time zones tagged with publisher S and version s1, but if
> they include the version info in ther data they send to some other
> client using a different tzdist server then there is no easy way for
> that other client to correlate the publisher/version with the data their
> tzdist servers up (which may only be for publisher A).
> 
> So I do think we need to preserve the underlying publisher/version
> tuples at the service level. If someone does want to aggregate, then
> they become a "real" publisher in some fashion (this is leading towards
> the idea of registering publisher ids). But I don't think the service
> document needs to delve too deeply into that beyond preserving the
> underlying publisher/version ids.

The one piece of the jigsaw which is not easy to resolve is that it
takes time for a short notice change to be processed by TZ. I CAN see a
case for publishing intermediate changes simply to get these changes out
more promptly ... sub versions which eventually roll into a formal
release of the data set. This still fits the publisher/version model,
but one would not publish data using a subversion, it would simply flag
to all users that some element has changed. Essentially ONLY viewing
TZid's which have changed need to be flagged so only users who are
looking at an affected set of data need to worry if the 'latest' version
is later than that used by their cached data.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 11 Dec 2014 11:28:55 -0500

Hi Lester,

--On December 11, 2014 at 4:03:46 PM +0000 Lester Caine 
<[email-masked]> wrote:

> Essentially ONLY viewing

OK, so my proposal is to include a publisher/version tuple in the list 
action time zone metadata. That will give clients the ability to track time 
zone data versions locally to determine when a change may be impactful. It 
won't force the publisher/version into the time zone data itself since that 
will unnecessarily invalidate ETags/changedsince behavior. If clients 
choose to make use of that additional information, that is entirely up to 
them (and outside the scope of tzdist itself - though it may be relevant to 
the CalDAV timezone-by-reference spec which is the other draft this WG has 
to work on).

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Thu, 11 Dec 2014 10:33:33 -0700

There seem to be two separate issues in the latest discussions.

    (1) Distribution of TZ data.

    (2) Create/Update event change notifications that may include TZ 
changes.

As to Distribution (#1) of updated TZ data:

     That is one of the points to this mailing list and I am still 
getting up to date.
     I still do not see the need for version information - still reading 
old posts.

As to the Create/Update (#2) it already has a mechanism - iTIP and my 
comments on that are:

I would think the achievable process would be to first have at event 
creation time the
organizers user agent make an attempt to get the latest up to date 
version of time zone and
distribute all or part of that TZ data with the event (or group of events).

Its not going to be possible for many small devices to track TZ versions 
or compute differences
and update the user to a schedule change resulting from TZ data changes. 
Explaining how
to do that, doing that correctly, is going to be a pain. If too many 
fail at this, inaccurately computed
TZ change computations is just as useless as not sharing any TZ data.

I don't think anyone wants every CUA when powered up to contact a TZ 
authority and look for updates,
then do all those recalculations on every event to determine if there 
are any changes the user needs
to see. This would be DNS level connections with larger data packets.

Which is why I think it is the event creators responsibility to get the 
up to date information
and if it happens to not be up to date at least everyone will be late or 
early :-)

When the organizer/CUA notices a significant TZ change has occurred, 
then then it iTIP handles
the redistribution of scheduled events. No need for a new mechanism. 
When the
organizer, or organizers CUA notices a TZ change, a person or automated 
process can
re-PUBLISH or  schedule the new updates with the new TZ data just as 
they do now.
Any iTIP compliant CUA can already handle this.

-- 

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

---

From: Lester Caine <[email-masked]>
Date: Thu, 11 Dec 2014 17:58:33 +0000

>     I still do not see the need for version information - still reading

You do not use any material on the internet which was publish in the
past and for which TZ data has now changed? The majority of users will
never be bothered but once tzdist is being used as a distribution
source, then one HAS to know what version was used to create the
material being looked at. This data will not be updated every time there
is an update, and the material may well involve areas of data that even
today is still being corrected and expanded.

> TZ change computations is just as useless as not sharing any TZ data.

Embedded clock devices will only be tracking one or perhaps two
timezones, and only need to know that their next transition has changed.
ETag or changedsince can certainly handle that since they are already in
sync and if not, then only the latest data is needed.

> Any iTIP compliant CUA can already handle this.

Race hazard!
Yes you can pray that the diary you are looking at is correct, but while
it may not be a very common event, DST offsets do change at short notice
and it's ONLY this type of race hazard we need to protect against. Once
again ... if a schedule is published and over night the up-coming change
is amended, then a simple use of the version mechanism which IS needed
for all historic data also protects against the race hazard of published
data not yet having been updated to reflect the new situation.

The current system is broken for many reasons. tzdist is still
perpetuating some of those problems such as different sets of TZid's
from different publishers, but this is an existing problem which can be
protected against. If you can explain how using 'changedsince' can
achieve the same protection then I would have less of a problem, but
that certainly can't be used to address the historic data management.

---

From: Doug Royer <[email-masked]>
Date: Thu, 11 Dec 2014 12:39:24 -0700

On 12/11/2014 10:58 AM, Lester Caine wrote:
> ...

> material being looked at. This data will not be updated every time 
> there is an update, and the material may well involve areas of data 
> that even today is still being corrected and expanded.

The 'it changes' part I understand. :-)

VTIMEZONE now optionally contains a LAST-MODIFIED property and not a 
CREATED property. Mandate LAST-MODIFIED and when it is newer than your 
copy, then its a newer version from that source.

 From RFC 5545:

       The optional "LAST-MODIFIED" property is a UTC value that
       specifies the date and time that this time zone definition was
       last updated.

Is that not a version? When the TZ authority source LAST-MODIFIED value 
is newer than yours, it has for whatever reason, updated the contents of 
the time zone definition. You may want to get the new copy.

> ...When the organizer/CUA notices a significant TZ change has 
> occurred, then then it iTIP handles the redistribution of scheduled 
> events. No need for a new mechanism. When the organizer, or organizers 
> CUA notices a TZ change, a person or automated process can re-PUBLISH 
> or schedule the new updates with the new TZ data just as they do now. 

I see that you may have incorrect TZ data at any point without live 
updates. We will never have live updates.

How is an update from a TZ server faster than an update from the 
organizer? Each way a CUA has to check for updates. Code will still have 
to be written for non-iTIP/TZ compliant CUAs both ways. Existing CUAs 
that are already iTIP compliant and correctly use the organizers TZ data 
will not have to have any changes, they will continue to work if we use 
the iTIP update process.

Unless your CUA continually pings/fetches/queries/whatever each time 
zone for any relevant event, and it does this every second its running 
or viewing any event, you can have that problem anyway. You solved 
nothing, congested your network, and made it more complicated. And that 
change *would* break existing iTIP/TZ compliant CUAs and force them to 
change their code.

In the 70's my city decided NOT to use switch from daylight savings 
time, because it made young school children walk to school in the dark 
for a week or two. So the city counsel decided to NOT switch from 
DAYLIGHT. The organizer of such an event would pick a TZ that matched 
the city clock and would not care about updates. The next year the 
school changed the school times, so the city then used DAYLIGHT/STANDARD 
again. No official TZ data would exist for that first year. The 
organizer would know what they wanted. And updated TZ data could be 
confusing, irrelevant, and incorrect with respect to the wall clock.

One city in Oregon (PST) on the Idaho border in order to take advantage 
of Idaho consumers advertise both MST times and PST times during the 
holiday shopping in order to not confuse MST customers with closing 
times. They want it at 10PM MST knowing it is 9PM PST. Silly stuff 
happens. They send email to MST customers with MST times, they send PST 
customers email with PST times.  Yes they only need to mark it in PST in 
their calendar and distribute to anyone, can you explain that in a popup 
to all non-technical calendar organizers? The problem exists in the 
non-technical users eye. What if the official MST time changes during 
that time. They may want it synced to their concept of PST, not an 
updated MST that the organizer may never know about. This event is in 
TZ-A distributed in TZ-B simply for estetics from a non-technical 
organizers viewpoint. If everyone uses the organizers TZ definition, 
everyone will expect the closing at the correct time on the viewed 
calendar, even with the TZ data is out of date because it will be 
converted from the incorrect included MST (really PST) to UTC, then to 
the correct MST.

Only the organizer knows when they want an event.

> that certainly can't be used to address the historic data management.

Yes. But the real problem seems to be that the organizer does not send 
TZ data or the CUA ignores it. This mailing list and any implementation 
will not fix existing code. And it seems a bit annoying to force CUAs 
that do currently work correctly and implemented correctly to break and 
force them to change their code.

--

---

From: Tim Parenti <[email-masked]>
Date: Thu, 11 Dec 2014 14:55:44 -0500

On 11 December 2014 at 12:58, Lester Caine <[email-masked]> wrote:

> one HAS to know what version was used to create the
> material being looked at.
>

If I recall correctly, it's been brought up repeatedly that one does not
have to know this specific information in order to detect changes.  At
minimum, to detect whether the timestamp you stored based on some version X
of the database is compatible with some version Y of the database (in
practice, a newer version), you, as a client, only need to store some
triple of data that both records the calculation made from version X and
allows the recalculation in version Y, so that a comparison can be made.

Mike Douglass' approach, outlined in
http://www.ietf.org/mail-archive/web/tzdist/current/msg01015.html, is for
this triple to contain UTC and local times (one calculated from the other
based on version X) and a tzid (to enable recalculation in version Y).
Another option would be to store the tzid alongside a calculated offset and
either UTC or local time.  From this information, you can determine the
rest as it was in version X, and compare it to version Y at will.

Yes, another possible triple would be to store UTC time, a tzid, and the
database version number X, but in order for the database version number to
be helpful (i.e., to calculate the local time as version X would convert
it), you also need to keep the data for version X around for any zone you
use, in addition to the current version Y that you're actually using.

Some of these approaches are more useful than others for different
applications, but I think that fits far better in a best practices document
than in the tzdist protocol.

That said, the tzdist protocol can help with these best practices in some
ways.  In particular, I think Paul's question of "I've got version tz2014a
of America/Los_Angeles; is that good enough?" is a useful one to be able to
answer.  (http://www.ietf.org/mail-archive/web/tzdist/current/msg01018.html)
 To ask this question, you only need to store one additional data point per
zone used, or ideally, one additional data point altogether.

--
Tim Parenti

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Dec 2014 09:22:35 +0100

On 12/11/14, 5:28 PM, Cyrus Daboo wrote:
> action time zone metadata.

What happens if the publisher doesn't publish a single database version
but instead versions the entries?

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Fri, 12 Dec 2014 00:34:02 -0800

Cyrus Daboo wrote:
> I don't think that really deals with Lester's issue. If the tzdist server itself
> does the aggregation, then the version information is specific to that one
> server e.g., it aggregates from publishers A & B which each have version a1 and
> b1 respectively, and generates a "virtual" publisher (itself)

This is too complicated.  There is no need for tzdist to support "virtual" 
publishers, or to provide special features for tzdist servers that do automatic 
aggregation, and more than there's need for the HTTP protocol to provide special 
features just for Google News.  If someone wants to publish a composite or 
compiled work, then they're a publisher and they can act like any other 
publisher; tzdist doesn't and shouldn't need to delve into the details of 
whether a publisher is providing aggregated or disaggregated data.

---

From: Lester Caine <[email-masked]>
Date: Fri, 12 Dec 2014 08:52:50 +0000

> but instead versions the entries?

I'd read this as just mirroring the 'changedsince' action, so that list
still returns either a full set of TZid's if this is a first read, or a
truncated set if this read is a refresh of what is cached already.
Essentially that is what 'changedsince' is intended to do, but by
managing the update properly one can ensure that the race problem is
avoided? If the event is published and it's VTIMEZONE simply says 2014j
but your tzdist updated returns 2014j1 one then one simply looks at the
effected TZid's to see if this update makes any difference. Ignore
VTIMEZONE and all th current problems remain without any cahnge to software?

The only real addition to the original process once one establishes a
method to ensure 'changedsince' is returning the SAME detail to
everybody is to allow older versions to be read. So a new reader of the
event can read 2014j - or use their cached copy of that! - and ensure
they have matching rules. Fixes the short term race hazard as well as
the archival data problem. I've used 2014j1 there deliberately since
that tags a yet unpublished change that could cause a problem. We would
not return 2014j1 via the version lookup, only the published 2014j and
2014j1 is actually a notification that can be transferred back up the
chain to TZ to be queued for inclusion in the next published update.
Closing the loop.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Dec 2014 10:00:35 +0100

On 12/11/14, 8:55 PM, Tim Parenti wrote:
>
> That said, the tzdist protocol can help with these best practices in
> some ways.  In particular, I think Paul's question of "I've got
> version tz2014a of America/Los_Angeles; is that good enough?" is a
> useful one to be able to answer.
>  (http://www.ietf.org/mail-archive/web/tzdist/current/msg01018.html)
>  To ask this question, you only need to store one additional data
> point per zone used, or ideally, one additional data point altogether.

To whom does one that question?  The meeting organizer?  The
communication path to that individual is not what I would call real
time.  After all, it is the meeting organizer with whom one must have a
common view, and not the tzdist server, which I think seveal people have
stated in several different ways.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Fri, 12 Dec 2014 09:23:48 +0000

> stated in several different ways.

Since the meeting organizer may well be sleeping when a short term
change is actioned, tzdist is the mechanism to publish that something
has changed. The meeting organiser will get to hear of the problem when
they wake up and if they have planned properly it is just a matter of
their publishing a revised agenda. In the meantime attendees who wake up
earlier will see that the data used by the event has changed overnight
and there is a potential problem. They know to check! This is why having
a common view of the VERSION of data being used is important and ideally
all publishers would return the same view of a version sourced from the
same original data?

tzdist sets a standard so that other users only need to worry about
'VTIMEZONE version' or some similar tag when publishing events. If the
version changes we at least have an indication that action may be
required ...

---

From: Tim Parenti <[email-masked]>
Date: Sat, 13 Dec 2014 20:23:20 -0500

On 12 December 2014 at 04:00, Eliot Lear <[email-masked]> wrote:
>
> After all, it is the meeting organizer with whom one must have a common
> view, and not the tzdist server, which I think seveal people have stated in
> several different ways.

I think that, as an attendee on an event, if you receive notification (by
syncing to a tzdist server) that the rules have changed for a relevant zone
and that a relevant event may be affected, you should be alerted, just like
the organizer of the event should be alerted.

If the attendee is alerted before the organizer, it should probably just be
informational, to the effect of "Time zone rules for Zone/Foo have recently
changed.  Be aware that the times of these affected events may be shifted
by the organizer."  When the organizer is alerted, they are given the
option to keep the same local time, keep the same UTC, or reschedule
altogether.  Then the attendees are notified of the change.

That said, I think that all of this falls under "best practice" for
calendaring applications and is squarely outside our scope here.

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Sun, 14 Dec 2014 10:33:29 +0000

> calendaring applications and is squarely outside our scope here.

But we do need to provide a mechanism that CAN identify that there has
been the change. Simply using 'latest' tzdist information does not do that.

---

From: Doug Royer <[email-masked]>
Date: Sun, 14 Dec 2014 11:36:27 -0700

On 12/13/2014 06:23 PM, Tim Parenti wrote:
>
> On 12 December 2014 at 04:00, Eliot Lear <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     After all, it is the meeting organizer with whom one must have a
>     common view, and not the tzdist server, which I think seveal
>     people have stated in several different ways.
>
>
> I think that, as an attendee on an event, if you receive notification 
> (by syncing to a tzdist server) that the rules have changed for a 
> relevant zone and that a relevant event may be affected, you should be 
> alerted, just like the organizer of the event should be alerted

Yes - exactly how I understand the issue.

> If the attendee is alerted before the organizer, it should probably 
> just be informational, to the effect of "Time zone rules for Zone/Foo 
> have recently changed.  Be aware that the times of these affected 
> events may be shifted by the organizer."  When the organizer is 
> alerted, they are given the option to keep the same local time, keep 
> the same UTC, or reschedule altogether.  Then the attendees are 
> notified of the change.
>

If a version type property is added - Without one, the problem is not 
detectable.

--