4 ms·

The author's proposal, for those who (understandably) did not glean it from the article, is that the UNIX timestamp becomes absolutely monotonic and, in the cas

The author's proposal, for those who (understandably) did not glean it from the article, is that the UNIX timestamp becomes absolutely monotonic and, in the case of leap seconds, a day becomes 86,401 UNIX seconds long. Right now UNIX days are always exactly 86,400 seconds long, and time goes backwards a second when a leap second is added. > I know there is a lot of smugness going on in developer circles where people get high on posting comments such as “of course it is like this. it’s the way we’ve done it forever, it’s the only way.” What the author perceives as "smugness" is a reaction to criticism of the status quo without understanding and addressing the benefits of the status quo. I'm not preemptively dismissing the author's proposal, but you would have to overcome some fairly serious hurdles. Most notably, you would not be able to reliably construct dates in the future, because it is not generally known when leap seconds will be added. So it is unknowable what the "monotonic timestamp" for Jan 1, 2023 00:00:00 is, for example. I think a better answer to the problem is the leap second smear that Google has implemented: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...

Udo 13y ago
OP here. I really wish this hadn't been submitted, but it's here so I might as well... > Most notably, you would not be able to reliably construct dates in the future You already need libraries for these functions. The only difference is that right now, those libraries have to calculate against a moving target instead of one that behaves predictably. I wrote this post a long time ago to suggest a strict(er) divide between computer timestamps and human timestamps, because Unix timestamps are in effect neither. There are countless apps that implicitly assume timestamps are linearly counted upwards. Most people would say those are bugs, but they'd only be right on superficial grounds. What most applications rightly want is a monotonic, predictable way to count the passing of time and to exchange that data with other apps. My idea was to introduce such a linear counter for apps that want it, not (as some people here obtusely suggested) replacing the Unix timestamp with this no matter the ecosystem breakage.
- haberman 13y ago
  > You already need libraries for these functions. I'm not sure if you caught my point. Library or no, it is impossible to construct future dates because it is unknown when leap seconds will be inserted until six months or so before it happens. Leap seconds are based on minute changes in the rotation of the earth, which are unpredictable. I added this to my comment later, but I think a better way to get a strictly monotonic timestamp is to smear the leap second: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l... > There are countless apps that implicitly assume timestamps are linearly counted upwards. There are also countless apps that implicitly assume that minutes are 60 seconds, hours are 3600 seconds, days are 86,400 seconds. Your scheme would break these apps.
  - Udo 13y ago
    I think we're misunderstanding each other. > Library or no, it is impossible to construct future dates because it is unknown > when leap seconds will be inserted until six months or so before it happens. This problem exists whether the Unix timestamp actually jumps or not. At some point, a reference table will have to be updated with the most current leap second data - otherwise you couldn't accurately count seconds between to points in time anyway. If that much precision is actually needed is another thing entirely. Again, the idea is just to make a cleaner separation between the two worlds. > Your scheme would break these apps. Again, and I already said this multiple times now, the idea is not to abolish the Unix timestamp and ignore whatever breaks. Instead I suggested to introduce a linear counter for apps that want it. I might be wrong of course, but I believe using this monotonic counter instead would greatly reduce complexity and potential for bugs in many applications.
    - haberman 13y ago
      > This problem exists whether the Unix timestamp actually jumps or not. No it doesn't. I can tell you authoritatively that the UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. That value is not dependent on future changes to the rotation of the Earth. Now it is true that I cannot tell you precisely how many physical seconds there are between now and then, because I do not know how many leap seconds will be added in the meantime. But in practice I think this is less critical. Applications that care about this probably use a more specialized time scale anyway. But it would be strange to put an appointment in your calendar for midnight and find that later on it had flipped to being at 11:59pm the previous day. > Again, and I already said this multiple times now, the idea is not to abolish the Unix timestamp and ignore whatever breaks. Instead I suggested to introduce a linear counter for apps that want it. I understand what you are saying. I'm just saying that your proposal trades one surprise for another. An app author might think "oh yes, a monotonic time sounds nice" and start using it, only to find that they are broken later because they were surprised that a minute could be 61 seconds long.
magila 13y ago
You can't know what the UNIX timestamp for Jan 1, 2023 00:00:00 is either. Is DST going to be in effect? What if the relevant governing body decides to change the offset of the time zone you are in?
- haberman 13y ago
  Good point, as it pertains to local time. You can authoritatively say the answer for UTC though.
  - CanSpice 13y ago
    No you can't, because leap seconds affect UTC as well. We don't know how many leap seconds are going to be added or subtracted between now and then.
    - haberman 13y ago
      It does not matter, because leap seconds do not affect the UNIX timestamp <-> UTC mapping. That is the whole point of what I am saying. The UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. I can tell you that right now even though I do not know how many leap seconds will be added between now and then.
      - CanSpice 13y ago
        Huh. I didn't know that the UNIX timestamp essentially gets recalculated at UTC midnight every day to ensure that midnight now = midnight yesterday + 86400. I take back my previous argument.
  - magila 13y ago
    But what does that really buy you? We already have to store such dates using a datetime struct to handle the common case where the user wants to deal in local time. In what context could you not handle UTC the same way as local time?

Udo 13y ago

OP here. I really wish this hadn't been submitted, but it's here so I might as well... > Most notably, you would not be able to reliably construct dates in the future You already need libraries for these functions. The only difference is that right now, those libraries have to calculate against a moving target instead of one that behaves predictably. I wrote this post a long time ago to suggest a strict(er) divide between computer timestamps and human timestamps, because Unix timestamps are in effect neither. There are countless apps that implicitly assume timestamps are linearly counted upwards. Most people would say those are bugs, but they'd only be right on superficial grounds. What most applications rightly want is a monotonic, predictable way to count the passing of time and to exchange that data with other apps. My idea was to introduce such a linear counter for apps that want it, not (as some people here obtusely suggested) replacing the Unix timestamp with this no matter the ecosystem breakage.

haberman 13y ago
> You already need libraries for these functions. I'm not sure if you caught my point. Library or no, it is impossible to construct future dates because it is unknown when leap seconds will be inserted until six months or so before it happens. Leap seconds are based on minute changes in the rotation of the earth, which are unpredictable. I added this to my comment later, but I think a better way to get a strictly monotonic timestamp is to smear the leap second: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l... > There are countless apps that implicitly assume timestamps are linearly counted upwards. There are also countless apps that implicitly assume that minutes are 60 seconds, hours are 3600 seconds, days are 86,400 seconds. Your scheme would break these apps.
- Udo 13y ago
  I think we're misunderstanding each other. > Library or no, it is impossible to construct future dates because it is unknown > when leap seconds will be inserted until six months or so before it happens. This problem exists whether the Unix timestamp actually jumps or not. At some point, a reference table will have to be updated with the most current leap second data - otherwise you couldn't accurately count seconds between to points in time anyway. If that much precision is actually needed is another thing entirely. Again, the idea is just to make a cleaner separation between the two worlds. > Your scheme would break these apps. Again, and I already said this multiple times now, the idea is not to abolish the Unix timestamp and ignore whatever breaks. Instead I suggested to introduce a linear counter for apps that want it. I might be wrong of course, but I believe using this monotonic counter instead would greatly reduce complexity and potential for bugs in many applications.
  - haberman 13y ago
    > This problem exists whether the Unix timestamp actually jumps or not. No it doesn't. I can tell you authoritatively that the UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. That value is not dependent on future changes to the rotation of the Earth. Now it is true that I cannot tell you precisely how many physical seconds there are between now and then, because I do not know how many leap seconds will be added in the meantime. But in practice I think this is less critical. Applications that care about this probably use a more specialized time scale anyway. But it would be strange to put an appointment in your calendar for midnight and find that later on it had flipped to being at 11:59pm the previous day. > Again, and I already said this multiple times now, the idea is not to abolish the Unix timestamp and ignore whatever breaks. Instead I suggested to introduce a linear counter for apps that want it. I understand what you are saying. I'm just saying that your proposal trades one surprise for another. An app author might think "oh yes, a monotonic time sounds nice" and start using it, only to find that they are broken later because they were surprised that a minute could be 61 seconds long.

magila 13y ago

You can't know what the UNIX timestamp for Jan 1, 2023 00:00:00 is either. Is DST going to be in effect? What if the relevant governing body decides to change the offset of the time zone you are in?

haberman 13y ago
Good point, as it pertains to local time. You can authoritatively say the answer for UTC though.
- CanSpice 13y ago
  No you can't, because leap seconds affect UTC as well. We don't know how many leap seconds are going to be added or subtracted between now and then.
  - haberman 13y ago
    It does not matter, because leap seconds do not affect the UNIX timestamp <-> UTC mapping. That is the whole point of what I am saying. The UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. I can tell you that right now even though I do not know how many leap seconds will be added between now and then.
    - CanSpice 13y ago
      Huh. I didn't know that the UNIX timestamp essentially gets recalculated at UTC midnight every day to ensure that midnight now = midnight yesterday + 86400. I take back my previous argument.
- magila 13y ago
  But what does that really buy you? We already have to store such dates using a datetime struct to handle the common case where the user wants to deal in local time. In what context could you not handle UTC the same way as local time?