3 ms·

> The timestamp is expressed as UTC seconds since 1970-01-01 That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those

> The timestamp is expressed as UTC seconds since 1970-01-01 That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?

wtallis 8mo ago
Do leap seconds even matter here? Doing anything involving DNS or certificates in a way that requires clock synchronization down to the second would seem to be asking for trouble.
- toast0 8mo ago
  Probably yeah, seconds don't really matter here. You would have to work hard for the 27 second difference to be material. But precision is nice. unixtime is almost certainly what is meant by the standard, but it is not the count of UTC seconds since 1970; unix time is the number of seconds since 1970 as if all days had 86400 seconds. UTC, TAI, and GPS seconds are all the same length, and the same number have happened since 1970, but TAI appears 37 seconds ahead of UTC because TAI has days with 86400 seconds, while UTC has some days with 86401 seconds and was 10 seconds ahead of UTC in 1970. unixtime and UTC are in sync because unixtime allows some days to encompass 86401 UTC seconds while unixtime only counts 86400 seconds.
- tialaramex 8mo ago
  Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye bye leap seconds. The body responsible has formal treaty promises to make UTC track the Earth's spin and replacing those treaties is a huge pain, so, the "hack" proposed is to imagine into existence a leap minute or even a leap hour that could correct for the spin, and then in practice those will never be used either because it's even less convenient than a leap second - but by the time they're asked to set a date for these hypothetical changes likely the signatory countries won't exist and their successors can just sign a revised treaty, countries only tend to last a few hundred years, look at the poor US which is preparing 250th anniversary celebrations while also approaching civil war.
  - imtringued 8mo ago
    I tried to think about and leap seconds on their own don't seem to be a real problem. The problem is that leap seconds, minutes, hours, days, years, etc are a human interface concept and therefore only make sense to humans, but we've decided to force machines to deal with these human interface concepts as the primary way of dealing with time, when only the presentation layer should even know what a leap second is.
    - tialaramex 8mo ago
      Leap seconds are not a human interface concept. Humans don't care. People who haven't thought very hard about this tend to believe humans care but they don't. If humans cared the existing systems couldn't exist. For more than a century we've all lived with time "zones" which are thousands of seconds wide and we're not bothered by that. Many of us have civil time systems which shift twice per year by 3600 seconds for really no good reason, and while that's annoying it's barely worth a brief mention on TV news or in small talk. Leap seconds are 3600 times smaller and happen way less often, they're entirely negligible. They existed because we thought we cared, and we actually don't care, and we thought it was pretty easy to do, and it actually wasn't very easy after all.
  - aragilar 8mo ago
    Which is how we get the October revolution in November.
    - tialaramex 8mo ago
      The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that offset between Old and New dates. The leap second is because the Earth's spin varies. The orbit isn't varying significantly, it's just not a whole number of day-night cycles which is inconvenient for us, but the spin actually varies. To "fix" this variation we have leap seconds. But unlike the very noticeable October versus November difference, a century of missed leap seconds adds up to much less than a minute of difference between solar time and civil time, and that's not something you'll actually notice.
mcpherrinm 8mo ago
It does mean Unix timestamps. The blog post doesn’t have the full details. You can read the RFC draft at https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe... It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.

wtallis 8mo ago

Do leap seconds even matter here? Doing anything involving DNS or certificates in a way that requires clock synchronization down to the second would seem to be asking for trouble.

toast0 8mo ago
Probably yeah, seconds don't really matter here. You would have to work hard for the 27 second difference to be material. But precision is nice. unixtime is almost certainly what is meant by the standard, but it is not the count of UTC seconds since 1970; unix time is the number of seconds since 1970 as if all days had 86400 seconds. UTC, TAI, and GPS seconds are all the same length, and the same number have happened since 1970, but TAI appears 37 seconds ahead of UTC because TAI has days with 86400 seconds, while UTC has some days with 86401 seconds and was 10 seconds ahead of UTC in 1970. unixtime and UTC are in sync because unixtime allows some days to encompass 86401 UTC seconds while unixtime only counts 86400 seconds.
tialaramex 8mo ago
Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye bye leap seconds. The body responsible has formal treaty promises to make UTC track the Earth's spin and replacing those treaties is a huge pain, so, the "hack" proposed is to imagine into existence a leap minute or even a leap hour that could correct for the spin, and then in practice those will never be used either because it's even less convenient than a leap second - but by the time they're asked to set a date for these hypothetical changes likely the signatory countries won't exist and their successors can just sign a revised treaty, countries only tend to last a few hundred years, look at the poor US which is preparing 250th anniversary celebrations while also approaching civil war.
- imtringued 8mo ago
  I tried to think about and leap seconds on their own don't seem to be a real problem. The problem is that leap seconds, minutes, hours, days, years, etc are a human interface concept and therefore only make sense to humans, but we've decided to force machines to deal with these human interface concepts as the primary way of dealing with time, when only the presentation layer should even know what a leap second is.
  - tialaramex 8mo ago
    Leap seconds are not a human interface concept. Humans don't care. People who haven't thought very hard about this tend to believe humans care but they don't. If humans cared the existing systems couldn't exist. For more than a century we've all lived with time "zones" which are thousands of seconds wide and we're not bothered by that. Many of us have civil time systems which shift twice per year by 3600 seconds for really no good reason, and while that's annoying it's barely worth a brief mention on TV news or in small talk. Leap seconds are 3600 times smaller and happen way less often, they're entirely negligible. They existed because we thought we cared, and we actually don't care, and we thought it was pretty easy to do, and it actually wasn't very easy after all.
- aragilar 8mo ago
  Which is how we get the October revolution in November.
  - tialaramex 8mo ago
    The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that offset between Old and New dates. The leap second is because the Earth's spin varies. The orbit isn't varying significantly, it's just not a whole number of day-night cycles which is inconvenient for us, but the spin actually varies. To "fix" this variation we have leap seconds. But unlike the very noticeable October versus November difference, a century of missed leap seconds adds up to much less than a minute of difference between solar time and civil time, and that's not something you'll actually notice.

mcpherrinm 8mo ago

It does mean Unix timestamps. The blog post doesn’t have the full details. You can read the RFC draft at https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe... It says: CAs MUST properly parse and interpret the integer timestamp value as a UNIX timestamp (the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds) and apply the expiration correctly.