4 ms·

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the

The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one does not and should not have to update the system clock or most unrelated applications, simply update tzinfo and you're done. Unfortunately, Unix time did not consider the effects of leap second, which broke the very foundation of Unix time and nullified all the benefits it had. A UTC change (leap second) will force you to update the system clock. There is a way out: we should stop keeping time in UTC, instead, we do the timekeeping in TAI. And we provide a system-wide facility called "utcinfo" database to handle TAI-UTC conversation. Just like tzinfo, but much easier, it only needs to store all the leap-second events. All problems solved! I'm aware that the leap second still causes some issues: the kernel still has to be notified for the upcoming leap second for its UTC APIs, but still better. The question is, why don't systems and libraries treat TAI as the first-class citizen of timekeeping? Why aren't we doing it right now? Because it's incompatible with Unix time, or it's something else?

nitwit005 7y ago
> Unfortunately, Unix time did not considered the effects of leap second The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.
- bcaa7f3a8bbc 7y ago
  It has nothing to do with my argument, there could be awareness, to the extents that Unix architects had seen it in the news, but still, it was not considered. I don't believe support of leap second was built into Unix and honored properly until 1990s, when NTP became prevalent. Also, the fact that Unix time starts before leap seconds were introduced made timekeeping in TAI an even stronger point. And I'm waiting for some insights on why it's not being done.
wodenokoto 7y ago
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 7y 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.

nitwit005 7y ago

> Unfortunately, Unix time did not considered the effects of leap second The change to UTC to include leap seconds was in 1972, which was after unix time came into existence.

bcaa7f3a8bbc 7y ago
It has nothing to do with my argument, there could be awareness, to the extents that Unix architects had seen it in the news, but still, it was not considered. I don't believe support of leap second was built into Unix and honored properly until 1990s, when NTP became prevalent. Also, the fact that Unix time starts before leap seconds were introduced made timekeeping in TAI an even stronger point. And I'm waiting for some insights on why it's not being done.

wodenokoto 7y ago

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 7y 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.