In that case you would be well advised to use a monotonic clock source, rather than a "date-generating" clock. In linux this is the difference between providing CLOCK_MONOTONIC or CLOCK_REALTIME as the first argument to clock_gettime().
But any API you might use to set a trigger for 2 seconds into the future is probably already based on a monotonic clock. Polling a realtime clock would make for a pretty convoluted implementation! -Rowan On 13 October 2017 at 18:42, Wout Mertens <wout.mert...@gmail.com> wrote: > Thank you, very interesting! > > The leap second behavior is slightly worrying, basically anything > time-based (animations etc) will take a second longer? What if you want an > engine burn to last 2 seconds, set a trigger for 2 seconds from now, and > then it's burning 50% longer? > > On Thu, Oct 12, 2017, 3:50 PM Stephan Buchert <stephanb...@gmail.com> > wrote: > > > This has not much to do with the original question, but as physicist I > > cannot resist: > > > > National institutes (NIST in the US, NPL in the UK, PTB in Germany, to > name > > just a few) provide reference times in UTC, which are distributed > nowadays > > also via the internet, e.g. the NTP protocol. Therefore clocks of > > computers, smart phone etc. are, if at all, synchronized more or less > > successfully to UTC, and the timestamps that a software like Sqlite > handles > > are in the vast majority UTC, possibly plus a timezone offset. For > example, > > the message by Keith Medcalf has been stamped *Wed Oct 11 21:53:05 UTC > > 2017.* > > > > What can go wrong?: > > > > 1) The local clock is synchronized now and then, in some cases as a > > consequence of the well-know leap seconds, by setting it abruptly to a > new > > time. Obviously this does not guarantee that the timestamps become > ordered > > the same as the events really happened. In the worst case a timestamp has > > the wrong day or even the wrong year (with potentially legal > consequences, > > e.g. for financial transactions). > > > > When is it right?: > > > > 2) Using the information from NTP, only the clock speed is adjusted to > > compensate for drifts. Leap seconds are announced in advance via NTP. But > > none of the major operating systems, Windows, Linux, Unix can internally > > represent times within leap seconds. Therefore the system clock is halted > > for the leap second. Calls for the system time within a leap second > return > > time stamps just before the leap second, having a small difference > between > > them such that their order is correct. > > > > Sqlite and applications are here at the mercy of the underlying system, > no > > matter how the time at the Sqlite level is presented, as floating point > > Julian day numbers, (milli- or micro) second counters from a certain > point > > in time (epoch) or so. Normally leap seconds don't need to be > > representable, as Sqlite/applications are not going to get exposed to > such > > time stamps (all the OSs cannot). But any timestamps are almost certainly > > (supposed to be) UTC, plus timezone offset. > > > > Finally UT1: > > > > 1) Unless you need to do stuff like tracking satellites, planets, stars > and > > other celestial objects with high precision from the Earth, you don't > need > > to know what it is. > > > > 2) UT1 is published by the https://www.iers.org/ as a daily correction > in > > SI seconds to UTC, distinguishing between predicted and final correction. > > As such UT1 does not have seconds, days etc. You can of course define a > UT1 > > day as between the times when the corrected UTC passes midnight, and then > > divide this "day" into 86400 "seconds". From the physical viewpoint this > > would be a bit weird because these seconds then have a different length > > than the standard SI second, and their length also varies from day to > day. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users