3 ms·
I deeply disagree with point 3. Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second t
by brmgb 7y ago
I deeply disagree with point 3.
Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit.
That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than an event with a smaller stamp happened before. You can't say anything about the ordering of events having the same timestamp but that remains true with or without leap second.
- jhayward 7y agoYou can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.
- brmgb 7y agoSure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time. Still, unless you actively mess with, Unix Time actually never goes backward.
- jhayward 7y agoIt happens all the time. Go talk to ops/sre types who run large fleets and ask them for their time stories, also ask them how much infrastructure and scaffolding they have to have in place to ensure that such things are as rare as possible. The consequences show up in large ways, as well, especially in distributed systems. Calculating an order of events, for instance, based on some notion of time is an obvious flaw. Even within a single system, assuming that a time stamp can be relied on to indicate order of events is wrong. If you work in domains where these things are important you will eventually come to understand that simplistic and naive statements such as "unix time never goes backwards" are the swords that programmers eventually fall upon.
- toast0 7y agoPOSIX defines gettimeofday [1], which fills a timeval with integer (time_t) seconds and integer (suseconds_t) microseconds. Is your concern over weather Unix Time is a time_t or a timeval? A time_t shouldn't go backwards (in normal operation), but a timeval does. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
- brmgb 7y ago> Is your concern over weather Unix Time is a time_t or a timeval? Yes, you could put it that way. I view Unix Time as referring strictly to the time_t part (seconds since Epoch) but I might be the one in the wrong. I didn't remember that the timeval part existed in the standard.
- _kst_ 7y agogettimeofday is obsolescent, but its replacement clock_gettime has the same issue. gettimeofday gives you a struct timeval with microsecond resolution. clock_gettime (which takes an extra argument specifying which of several clocks to use) gives you a struct timespec, with nanosecond resolution. https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
- lifthrasiir 7y agoTechnically speaking double negative leap seconds will break the monotonicity of time_t as well. Fortunately for us, there is no provision of double (positive or negative) leap seconds [1]; ISO C's range for tm_sec, which allows for 61, was a mistake [1; "not really UTC in 1989/1990" section]. [1] https://www.ucolick.org/~sla/leapsecs/timescales.html#UTC https://www.ucolick.org/~sla/leapsecs/timescales.html#UTC