4 ms·

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 i

by 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.
- __david__ 13y ago
  > I can tell you authoritatively that the UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. That assumes the calendar definition does not change. What if a 10 month calendar with a new year that starts in spring somehow becomes widely popular and adopted as the standard sometime in the next 10 years? Then suddenly 2023-01-01 is not 1672560000 and is actually 1680332400.
  - haberman 13y ago
    UTC is defined in terms of days. UTC calendar dates are presumed to use the Gregorian calendar. 2023-01-01 in the Gregorian calendar maps to a specific day (Julian day 2459946). If you wanted to use a different calendar, you would need to map it to Julian days also to convert between the two. The idea that the world would suddenly change to a new calendar is highly unlikely, and if it did happen it is not at all clear what the correct behavior would be for future dates that had been specified before the switch.

by Udo 13y ago

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.

__david__ 13y ago
> I can tell you authoritatively that the UNIX timestamp for 2023-01-01 00:00 UTC is 1672560000. That assumes the calendar definition does not change. What if a 10 month calendar with a new year that starts in spring somehow becomes widely popular and adopted as the standard sometime in the next 10 years? Then suddenly 2023-01-01 is not 1672560000 and is actually 1680332400.
- haberman 13y ago
  UTC is defined in terms of days. UTC calendar dates are presumed to use the Gregorian calendar. 2023-01-01 in the Gregorian calendar maps to a specific day (Julian day 2459946). If you wanted to use a different calendar, you would need to map it to Julian days also to convert between the two. The idea that the world would suddenly change to a new calendar is highly unlikely, and if it did happen it is not at all clear what the correct behavior would be for future dates that had been specified before the switch.