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

[Tim Parenti <[e-mail]>]

On 11 December 2014 at 12:58, Lester Caine <[e-mail]> 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