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

From: "tzdist issue tracker" <[email-masked]>
Date: Thu, 23 Oct 2014 14:55:49 -0000

#32: managing historical data

 If I provide archived data that has been created using the
 current set of timezone data and in ten years time someone is accessing
 that data they need to be able to process the data using the SAME view
 of the timezone data. This may well have changed so that the current
 data set is different, and while 'changed_since' can say that there has
 been a change, it provides no basis on which to access just what has
 changed in the intervening 10 years. The user needs to be able to ask
 for the correct view from ten years ago as they did not have that data
 as a starting point with which to use the current data.

 If we haven't built the handling of this into the standard now, then in
 ten years time the historic data is unusable. Or we need a different
 source of tz data that can be relied on in the future for that
 application.

-- 
--------------------------------+------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:
Component:  service             |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/32>
tzdist <http://tools.ietf.org/tzdist/>

---

From: "tzdist issue tracker" <[email-masked]>
Date: Fri, 24 Oct 2014 16:13:47 -0000

Comment (by [email-masked]):

 Looking for elaboration from Lester on this point, as well as whether it
 needs into a base spec.

-- 
--------------------------------+-------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:
Component:  service             |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/32#comment:1>
tzdist <http://tools.ietf.org/tzdist/>

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 24 Oct 2014 18:18:03 +0200

failing agreed orthography, uses

"timezone data"
instead of
"time zone data"

-> not good for text search

On Fri, Oct 24, 2014 at 6:13 PM, tzdist issue tracker
<[email-masked]> wrote:
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Fri, 24 Oct 2014 18:14:00 +0100

>  Looking for elaboration from Lester on this point, as well as whether it

The current problem with maintaining historic data is that while most
sources of TZ are reasonably similar, there is a lack of clarity at
times as to just which version of data is being used. In order to review
legacy material it has at times been necessary to reverse engineer the
correct view of the data used. Which is one of the reasons I've been
building a selectable database of tz data. UTC normalized data has been
in use for some time, but exact local time it was normalize from may be
difficult to establish.

Once a more reliable source of data is available it should be easier to
maintain this type of material going forward, but it is essential that
having used a current version of the tz data it is possible to recall
the same view of the data in order to work with the same local offsets
that the data was created with.

Since there are only ever perhaps 1 update per month, there are only a
small number of versions of data to keep track off, and on the whole the
majority of TZ records never change, so only a small set of differences
need to be managed. Adding a version field to the url structure solves
the problem, and would allow material being processed to be tagged with
the appropriate data version.

I would probably view this as optional, EXCEPT that if one takes the
situation of a simple device which is also creating a log of it's data
now correctly using UTC timestamps, it also needs to log any change in
version of data set used while creating that log. To that end even a
simple device only perhaps using 'expand' to obtain its local time data
needs to be able to provide a monitoring site with the correct set of TZ
data with which to view the file. Encoding TZ data into the timestamp
simply does not work, a separate cleanly defined TZ id is essential,
especially when one starts looking at a mobile device moving between
timezones.

( I'll rework the other thread about 'generic' TZ datasets in order to
hopefully explain that side of the problem better, although I did think
it was already pretty good )

-- 
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 19:27:59 +0200

On Fri, Oct 24, 2014 at 7:14 PM, Lester Caine <[email-masked]> wrote:
> sources of TZ
TZ = time zone?

sources of time zone?

What is that? A law that creates a time zone?

Or does TZ stand for time zone data?

>  are reasonably similar
what is "reasonably similar"? What is the source for that claim?

Just on the WebEx interface one could see "Northern Europe Summer
Time", "Eastern Europe Summer Time", "GMT Summer Time" and "Europe
Summer Time". I have never before seen so much non-intuitive Summer
Time names before.

And if I google for "Northern Europe Summer Time" then there are only
ten results at least half of them related to WebEx.

What sources constitute "most sources"?

I didn't spent any time to read further if already the first half of
the first sentence is so hard to parse.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Paul Eggert <[email-masked]>
Date: Fri, 24 Oct 2014 11:02:42 -0700

Lester Caine wrote:
> version of data set used while creating that log.

That's not needed in the simple devices that I help maintain.  They log UTC.

If devices need to put local time into a log for some reason, then they can log 
the UTC offset.  That is simpler and more reliable than logging the tz version 
number would be.

The problem of managing historical data is one that primarily concerns 
operations and system maintenance.  It's not something that low-level devices 
should need to worry about.  So it should be OK to make any version-control 
features optional.

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 24 Oct 2014 20:27:59 +0200

On Fri, Oct 24, 2014 at 8:02 PM, Paul Eggert <[email-masked]> wrote:
>> now correctly using UTC timestamps,
what is "now correctly"?

>>  it also needs to log any change in
> If devices need to put local time into a log for some reason, then they can
> log the UTC offset.  That is simpler and more reliable than logging the tz
> version number would be.
Why is that more reliable? Can there be different offsets for one
version of a collection of time zone data? Since you are the
maintainer of the IANA time zone database, could it be that you only
talk about the IANA TZDB and such behaviour is a specificity of the
IANA time zone database?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Fri, 24 Oct 2014 19:57:26 +0100

On 24/10/14 19:02, Paul Eggert wrote:
> If devices need to put local time into a log for some reason, then they
> can log the UTC offset.  That is simpler and more reliable than logging
> the tz version number would be.

You are right. I was mixing up a problem we had with legacy log files
which is avoided by logging the right data in the first place. However
it is still important to be able to identify the data set being used by
the device in case there is a question about accuracy of the logged data.

> operations and system maintenance.  It's not something that low-level
> devices should need to worry about.  So it should be OK to make any
> version-control features optional.

Software that needs to support archival data simply need to say if a
suitable source is not available, but again even if the source is unable
to provided an historic few of the data, the version number is still an
important audit device.

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 24 Oct 2014 21:05:51 +0200

On Fri, Oct 24, 2014 at 8:57 PM, Lester Caine <[email-masked]> wrote:
> You are right.
No he is not. If the "need to put local time into a log for some
reason", then it does not mean that "they can log UTC offset".

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

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

> reason", then it does not mean that "they can log UTC offset".

Log sequence is gauranteed by the use of UTC base, and since we do not
need to know about any other time than the logged time, the offset is
all that is needed. BUT the audit trail still needs to know if the
correct offset was used for that offset which is where a version stamp
is important.