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
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!
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>
> > 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
> > just a few) provide reference times in UTC, which are distributed
> > 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
> > are in the vast majority UTC, possibly plus a timezone offset. For
> > 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
> > time. Obviously this does not guarantee that the timestamps become
> > 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
> > 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
> > time stamps just before the leap second, having a small difference
> > them such that their order is correct.
> > Sqlite and applications are here at the mercy of the underlying system,
> > matter how the time at the Sqlite level is presented, as floating point
> > Julian day numbers, (milli- or micro) second counters from a certain
> > in time (epoch) or so. Normally leap seconds don't need to be
> > representable, as Sqlite/applications are not going to get exposed to
> > 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
> > other celestial objects with high precision from the Earth, you don't
> > to know what it is.
> > 2) UT1 is published by the https://www.iers.org/ as a daily correction
> > 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
> > 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
> > _______________________________________________
> > sqlite-users mailing list
> > firstname.lastname@example.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> sqlite-users mailing list
sqlite-users mailing list