Terje Mathisen writes: > [email protected] (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. 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 > [email protected] > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
