"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin
> Le 16 janv. 2015 à 08:42, Harlan Stenn <st...@ntp.org> a écrit : > > Terje Mathisen writes: >> cmad...@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. How can we take into account an unknown number of leaps? I will listen attentively to your presentation in Bruxelles. I can see how it might be feasible…. But I will have to check with Schrodinger's cat first. > >> 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. cron is a notoriously bad scheduler. It only wakes up every minute to check the schedule tasks, so you can’t be sure of getting accurate execution times. It am not sure it is relevant either, as events are scheduled in terms of absolute times so will be correct whether or not a leap second is scheduled. Task execution on a callback, interval timer event is different. One scheduled for execution in 5 seconds, 3 seconds prior to a positive leap second will get dispatched 4 TAI seconds later, but from a legal point of view will be dead on. However if that is not already fixed, it could be. > > H > -- >> 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 >> >> -- >> - <Terje.Mathisen at tmsw.no> >> "almost all programming can be viewed as an exercise in caching" >> >> _______________________________________________ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
