[ntp:questions] Leap second to be introduced in June
stenn at ntp.org
Fri Jan 16 07:42:33 UTC 2015
Terje Mathisen writes:
> cmadams at cmadams.net (Chris Adams) wrote:
> > Also, you can't properly represent future timestamps (necessary for some
> > things) as seconds since an epoch, and that's pretty widely used. By
> > that I mean that the number of seconds between 2015-06-30 23:59:00 and
> > 2015-07-01 00:00:00 has changed since last month.
The General Timestamp API handles this case, as those timestamps track
the "version number" of the timescale. If you specify "noon at (some
future date)", an absolute timestamp, and between now and then some leap
seconds are added, they'll be added here, too.
> And this is _exactly_ why it is always a bad idea to use (UTC) seconds
> for those future timestamps:
> If you actually mean that something has to happen N seconds from now,
> that future timestamp has to be in TAI, since using UTC would obviously
> blow up across any leap second, right?
If one used a relative/difference timestamp for this, then we're in the
same boat and we might need some sort of trigger or signal to indicate
that a leap event has happened.
We're often in a similar boat though, if the clock "steps" during the
interval this relative/difference timestamp covers. This should
arguably be an option for cron jobs and timer events.
> If you instead meant a calendar event, then you need a different
> timescale which is either Julian Day Number (JDN) or YMD, followed by
> either HMS or an offset into the day, followed by the applicable time zone.
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"
> questions mailing list
> questions at lists.ntp.org
More information about the questions