Hacker News Reader

Comment by School-Cotton | Hacker News Reader

You’re wrong and have the situation exactly backwards.

If a day has 86,401 or 86,399 seconds due to leap seconds, POSIX time still advances by exactly 86,400.

If you had a perfectly accurate stopwatch running since 1970-01-01 the number it shows now would be different from POSIX time.

View on HN

Wait, why would it be different?

Because a day, that is the time between midnight UTC and midnight UTC, is not always exactly 86400 seconds, due to leap seconds. But Unix time always increases by exactly 86400.

Unix time is not monatomic. It sometimes goes backwards.

Strictly speaking Unix time is monotonic, because it counts integer number of seconds and it does not go backwards, it only repeats during leap seconds.

This feels like semantics. If a counter repeats a value, it's effectively gone backwards and by definition is not monatomic.

A delta between two monatomic values should always be non-negative. This is not true for Unix time.

“Monotonic” means non-decreasing (or non-increasing if you’re going the other way). Values are allowed to repeat. The term you’re looking for is “strictly increasing.”

I guess this hinges on whether you think Unix time is an integer or a float. If you think it's just an integer, then yes, you can't get a negative delta.

If, however, you think it's a float, then you can.

POSIX does define "the amount of time (in seconds and nanoseconds) since the Epoch", for the output of clock_gettime() with CLOCK_REALTIME [0]. That "amount of time" must be stopped or smeared or go backward in some way when it reaches a leap second. This isn't the 80s, we have functions that interact with Unix time at sub-second precision.

[0] https://pubs.opengroup.org/onlinepubs/9799919799/functions/c...

Reply on news.ycombinator.com