Re: [Tzdist] Create and distribution process of events with TZ data.

[Doug Royer <[e-mail]>]

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

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

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

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.

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

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.

-- 

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