Hacker News Reader

Comment by spiderice | Hacker News Reader

What would using TAI solve exactly? I'm unfamiliar.

TAI is monotonic clock, and isn't adjusted for solar time of day, it could be considered universal as TAI would be the same between any 2 points, but UTC is adjusted for earths rotation, so a theoretical mars UTC would end up out of sync with earth UTC.

EDIT: info below is incorrect about UTC not being monotonic, as pointed out in thread but is useful for monotonic vs non-monotonic:

In UTC you can jump forward or back, so it's possible to do an operation after another operation but have a timestamp before it, which is bad for many reasons, top being auditing.

do operation one at T0 do operation two at T1 do operation three at T-1

in TAI it would always be do operation one at T0 do operation two at T1 do operation three at T2

I'm pretty sure UTC is monotonic too, its unix timestamps that really are the true mess

Yeah you are right, when a leap second is introduced it becomes 23:59:60 (monotonic) in utc, while with unix-time a normal way to handle it is to repeat 23:59:59 twice (non-monotonic).

Leap seconds can be negative.

A negative leap second means that 23:59:59 is skipped, you go from 23:59:58 to 00:00:00, which is monotonically increasing, in both UTC and unixtime.

Positive leap seconds are monotonically increasing in UTC, where you get 23:59:60 between 23:59:59 and 00:00:00, but not in typical implementations of unix time where 23:59:59 repeats, and with milliseconds you go (breifly) 58.999 -> 59.0 -> 59.999 -> 59.0 -> 59.999 -> 0.0

If you're only counting seconds, then both UTC and unixtime are always monotonically increasing.

Wrong. The very topic of this discussion, leap seconds, are non-monotonic adjustments to UTC.

In what way are leap seconds non-monotonic in UTC?

UTC is monotonic, even during leap seconds. (A positive leap second adds a 23:59:60; no timestamp ever repeats, the clock never moves backwards.)

(Negative leap seconds are similar, and do not affect the monotonic property.)

POSIX/Unix timestamps, however, are non-monotonic. But that's a different timescale.

Link for anyone interested: https://en.wikipedia.org/wiki/International_Atomic_Time

I'm not sure how this differs much in practice from UNIX time

Datetime storage would consist of two explicit parts: one free from leap seconds (similar to the raw timestamp you get from a GPS receiver), and description of when leap seconds happen, so that you can transform the leap-second-free timestamp into UTC. Feels like a more robust way in principle to me.

So like a CRDT for time

CRDT = Conflict-free replicated data type, https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

Reply on news.ycombinator.com