Subject: [Tzdist] [tzdist] #31 (service): Include leap seconds?

From: "tzdist issue tracker" <[email-masked]>
Date: Thu, 23 Oct 2014 11:52:48 -0000

#31: Include leap seconds?

 If you are going to work with historical data it might be important to
 know at which points in time leap seconds have been inserted into the UTC
 time scale, so it would be very helpful if the tzdist protocol would
 provide a way to distribute a list of leap seconds as provided by the NIST
 leap second file, or the leap second file included in the TZ data base.

 Nowadays the NTP protocol is mostly used to synchronize time between
 computers and other devices. However, there's also the new Precision Time
 Protocol (PTP, IEEE 1588) which uses time stamps based on TAI, and is used
 more and more in new applications.

 If you want to relate TAI to UTC at a given (current, or past) time you
 need to know *when* a leap second will be, or has been inserted in the UTC
 time scale.

 So if this information could also be distributed via the tzdist protocol
 this would be very helpful for future interaction of systems based on TAI
 and UTC.

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

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 23 Oct 2014 08:28:57 -0400

Steve Allen proposed a solution to this in his Aug 20 post: 
http://www.ietf.org/mail-archive/web/tzdist/current/msg00070.html

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 13:45:05 +0100

>  this would be very helpful for future interaction of systems based on TAI

I dispute the suggestion that this is important for historic data.
It only has relevance if the historic data has only been stored using
unix epochs at which time the debate is to if the original 'clock' even
used leap seconds?

Yes the table of leap seconds and any new entries in that table are
important, but historic material should be managed using 'day' as the
base unit side stepping any problems caused by the actual length of a day.

It can be argued that leap seconds are outside the charter of this
workgroup, and they should instead be part of one of the time
transmission standards, but on the same debate, tz data should perhaps
be part of the time standards rather than a separate isolated standard?

When using web based embedded devices - say a central heating controller
- we need a time source and an indication of when the DST changes
happen, which should probably be via the clock source, but practically
settings still only need to be a local 7 day calendar, and only the time
on the clock needs to change. In all this, the leap second would just be
a slight realignment of the clock rather than something important?

-- 
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: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 15:10:56 +0200

> unix epochs at which time the debate is to if the original 'clock' even

Doesn't this depend on the kind of historic data you are evaluating?

If you are postprocessing data which depends on time *intervals* then 
the number of leap seconds in this interval may well be important.

> a slight realignment of the clock rather than something important?

However, if you are using automated measurement systems which are for 
example based on the LXI specs? LXI depends on PTP:
http://www.ni.com/white-paper/7255/en/

Since PTP depends on TAI you need the number of leap seconds inserted 
until a given point in time if you want to convert that time to UTC, or 
even local time.

Applications for which the leap second information is not required can 
simply ignore the leap second information.

Martin

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 15:13:24 +0200

> http://www.ietf.org/mail-archive/web/tzdist/current/msg00070.html

Sorry, Steve's proposal fell off my radar, so it's good we now have an 
issue to track this.

Martin

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 14:37:08 +0100

> the number of leap seconds in this interval may well be important.

That some historic data may have been created using unix epochs is a
fact, but that data has to be processed with the same software that
created it in order to return the correct time. Other more reliable
storage methods use date and time in a manor that there is less reliance
on establishing if the correct number of leap seconds were included in
the first place.

It is perhaps the same problem as historic timeshots of the DST data. If
a system is reliant on only unix epochs with leapseconds added, then any
data post the addition of a new leap second needs correcting just as a
DST change will affect previously generated data.

There has been a long discussion on another list about tidying up the C
time library and much of the sticking point is around making seconds
work as a base while a simple switch to time being a 'fraction' of a day
solves many of the problems, a timestamp becomes a simple pair of 32bit
numbers ...

---

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Oct 2014 17:39:43 +0200

Adding comment from Paul to the list.

I think that leap second discussions shoudl go wit that thread.

The standard tz distribution has leap second information, and if we add its
binary format as a media type it should all work.  Different distributions
use different names for it, though; the default is the somewhat-awkward
low-level naming convention TZ='../zoneinfo-leaps/America/
Los_Angeles' to get Los Angeles time with leap seconds.  Presumably a
better naming convention could be standardized.

On Thu, Oct 23, 2014 at 3:37 PM, Lester Caine <[email-masked]> wrote:

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

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58