I feel safer now :) On Fri, Oct 13, 2017, 12:57 PM Rowan Worth <row...@dug.com> wrote:
> 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
