Possible bug with strftime('%s') < strftime('%s')

Possible bug with strftime('%s') < strftime('%s')

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
[hidden email]http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: Possible bug with strftime('%s') < strftime('%s')

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?

> 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
> [hidden email]> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users>

Re: Possible bug with strftime('%s') < strftime('%s')

On 2017/10/13 12:42 PM, Wout Mertens 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?

I sincerely hope you are making a bot for Kerbal space program and not
actually working for NASA.... :)

Re: Possible bug with strftime('%s') < strftime('%s')

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!

> 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 <[hidden email]>
> 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
> > [hidden email]> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users> >
> _______________________________________________
> sqlite-users mailing list
> [hidden email]> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users>

Re: Possible bug with strftime('%s') < strftime('%s')

> 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 <[hidden email]> 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 <[hidden email]>
> > 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
> > > [hidden email]> > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users> > >
> > _______________________________________________
> > sqlite-users mailing list
> > [hidden email]> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users> >
> _______________________________________________
> sqlite-users mailing list
> [hidden email]> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users>