3 ms·

Obviously, given the article and the discussion I am wrong, but what you propose sounds to me exactly like the definition of unix time: The number of seconds s

Obviously, given the article and the discussion I am wrong, but what you propose sounds to me exactly like the definition of unix time: The number of seconds since January 1. 1970 UTC. Even if UTC counts the same second twice, this does not change how many seconds has elapsed since the unix epoch. If you click through the articles reference to wikipedia and again from there, you will end up on "The Open Group Base Specifications Issue 7, 2018 edition"[1] Which says: > The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. Which again sounds like there is absolutely no reason to double count or skip seconds in unix time. However, I am not quite sure of the implication of the formula written there, but I fear that it says that the number of seconds since the epoch is defined, not as the number of seconds since the epoch, but by the UTC definition of the current time. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

bcaa7f3a8bbc 8y ago
Thanks for the interesting link, good to know! So we are in fact, pretty close to a monotonically-increasing, TAI-like Unix clock. The original article said, > Each Unix day has the same number of seconds, so it can’t just add an extra second – instead, it repeats the Unix timestamps for the last second of the day. Your POSIX link says, > As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. I'm not a expert on timekeeping, but it appears the only problem here is that the Unix time is bounded by a 86,400-second day, which I guess was meant to make a Unix day predictable, so we still have to double count or skip seconds. It seems the only thing we need to make Unix time monotonic is simply removing the 86,400 seconds Unix day from specification. On the other hand, it means a Unix day would be unpredictable and it would be impossible to calculate a Unix time without a database, and difficult calculate future Unix time using calendar time. So TAI doesn't automatically solve every problem, everything comes with a tradeoff. But I think a unpredictable Unix day should be fine for purpose of an internal system clock, so perhaps it's still not a bad idea.

bcaa7f3a8bbc 8y ago

Thanks for the interesting link, good to know! So we are in fact, pretty close to a monotonically-increasing, TAI-like Unix clock. The original article said, > Each Unix day has the same number of seconds, so it can’t just add an extra second – instead, it repeats the Unix timestamps for the last second of the day. Your POSIX link says, > As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. I'm not a expert on timekeeping, but it appears the only problem here is that the Unix time is bounded by a 86,400-second day, which I guess was meant to make a Unix day predictable, so we still have to double count or skip seconds. It seems the only thing we need to make Unix time monotonic is simply removing the 86,400 seconds Unix day from specification. On the other hand, it means a Unix day would be unpredictable and it would be impossible to calculate a Unix time without a database, and difficult calculate future Unix time using calendar time. So TAI doesn't automatically solve every problem, everything comes with a tradeoff. But I think a unpredictable Unix day should be fine for purpose of an internal system clock, so perhaps it's still not a bad idea.