Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Cyrus Daboo <[e-mail]>]

Hi Lester,

--On December 9, 2014 at 10:56:06 PM +0000 Lester Caine 
<[e-mail]> wrote:

> But if it is made optional, how do you ensure that you are using the
> same data as another information source. Pray that both are published
> with the same version?

Today one might need to pray, but once tzdist is deployed and in use the 
goal is that users can rely on the data they have to be up to date and 
accurate (just as much as one can rely on an NTP server to give your device 
the correct time, or rely on the user having set the correct local time 
zone for the device etc).

We can't put a version property into the time zone data served by tzdist 
because that would mean that every time zone resource would change every 
time the overall database version is updated - even though only a small 
number of "real" changes took place. That would defeat the purpose of the 
"changedsince" behavior for the list action. Note, that if it is important 
for clients to know the version number, then that is available via the 
capabilities, or if the tzdist server supports alternate versions, via the 
/versions URI path behavior. That said, we could add some guidance/warnings 
about this:

    Until tzdist services are widely deployed and used, it is possible that
    users of calendar data may have different versions of time zone data on
    their devices, with those different versions having differing UTC
    offset and daylight saving time rules. This could lead to apparent
    differences in local or UTC times for meetings, potentially resulting
    in meetings being missed. For better reliability in such an
    environment, clients would need a way to ensure that all devices
    viewing a particular event are synchronized with regard to the same
    time zone data version for any time zones referenced by that event. One
    approach is to include the time zone data used for an event directly in
    that event (e.g., including an iCalendar "VTIMEZONE" component in the
    iCalendar object - the default behavior for iCalendar today).
    Alternatively, clients can include a URI that describes the source (and
    relevant version information) for the time zone data used by the
    creator of the meeting, allowing other users and devices to verify that
    the time zone data at that source matches what they have for the same
    time zone identifier.

-- 
Cyrus Daboo