No, it really shouldn't. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Owen DeLong <owen@delong.com> wrote: On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote:
On (2012-07-03 12:46 -0700), Owen DeLong wrote:
If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write.
If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now > foo, virtually never expects time to move backwards.
Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers.
UTC doesn't move backwards (it goes 59 -> 60 -> 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that.
UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58->59->00 most of the time, but during a leap second, it should go 58->59->59->00). It's not so much going backwards as dropping a chime.
It is well known that leap seconds exist.
Quite. But it is not well known that unixtime travels backwards.
In part because it shouldn't actually do so. It should simply chime 59 twice. Owen