4 ms·

I guessed most big services would be using something akin to time smearing [1] since the first big leap-second outages years ago. Is there any reason why cloudf

I guessed most big services would be using something akin to time smearing [1] since the first big leap-second outages years ago. Is there any reason why cloudfare would be unable to use this technique? [1] https://developers.google.com/time/smear https://developers.google.com/time/smear

wyager 10y ago
It's pretty lame that a lot of software is so fragile that it breaks if we give it the correct time. The solution here is that any software that relies on accurate timing and/or breaks when you change the time should be using epoch seconds, not any sort of human-oriented time format.
- rspeer 10y ago
  Leap seconds are a change to the number of UTC epoch seconds.
  - wyager 10y ago
    > Leap seconds are a change to the number of UTC epoch seconds. UTC is different from epoch time. Epoch time by definition does not count leap seconds. https://en.m.wikipedia.org/wiki/Unix_time https://en.m.wikipedia.org/wiki/Unix_time
    - zerd 10y ago
      But it is affected by leap seconds. According to the example labeled "Unix time across midnight when a UTC leap second was inserted on 1 January 1999" the unix time went backwards. So using epoch/unix time does not help.
    - EGreg 10y ago
      Is it safe to say that time() in php and Date.now() in JS do not care about leap seconds?
      - perennate 10y ago
        From [1], it is likely messier than that: > The time() function will resolve to the system time of that server. If the server is running an NTP daemon then it will be leap second aware and adjust accordingly. PHP has no knowledge of this, but the system does. > It took me a long time to understand this, but what happens is that the timestamp increases during the leap second, and when the leap second is over, the timestamp (but not the UTC!) jumps back one second. [1] http://stackoverflow.com/questions/7780464/is-time-guaranteed-to-be-leap-second-aware http://stackoverflow.com/questions/7780464/is-time-guarantee...
        EGreg 10y ago
        It would seem much simpler to just use TAI for timestamps, and get civil datetimes from UTC. Why didn't people do this? Why use UTC for timestamps??
        rspeer 10y ago
        That doesn't seem simpler at all. - UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year. - Converting UTC timestamps to human-readable UTC times is simple modular arithmetic. A beginner in any programming language can do it. Converting TAI to UTC requires a lookup table, and it must be updated after the software is released. What would be simpler would be ending the use of leap seconds for a millennium or so.
        userbinator 10y ago
        "- UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year." Isn't it the other way around, since TAI has no leap seconds? "What would be simpler would be ending the use of leap seconds for a millennium or so." That effectively means using TAI consistently, which is what software not aware of leap seconds would be doing anyway (despite the fact that it's actually working with UTC.)
    - nshepperd 10y ago
      "Does not count leap seconds" has to win some kind of award for misleading terminology. I'd wager it's responsible for a significant portion of leap second bugs due to confusion & misunderstanding about what Unix time is: It sounds like what it means is that Unix time counts the number of real, actual, by-the-clock seconds that have passed since the epoch. That would be logical. But what it actually means is that it counts the number of real, actual, by-the-clock seconds, minus the number of those those that have been designated "leap seconds". That is to say, whenever a "leap second" occurs, the nice monotonic isotonic progress of unix time is mutilated by suddenly adding or removing 1 to the total count so far. That's what "does not count leap seconds" means, and sometimes even what "ignores leap seconds" means (which is of course even worse terminology).
      - wyager 10y ago
        Shit, you're right. It had me totally fooled.
dingaling 10y ago
And alternatively I guessed that big services like Cloudflare, responsible for fronting 2.5 million websites, would have been running a preproduction environment clocked-forward to 2017.

wyager 10y ago

It's pretty lame that a lot of software is so fragile that it breaks if we give it the correct time. The solution here is that any software that relies on accurate timing and/or breaks when you change the time should be using epoch seconds, not any sort of human-oriented time format.

rspeer 10y ago
Leap seconds are a change to the number of UTC epoch seconds.
- wyager 10y ago
  > Leap seconds are a change to the number of UTC epoch seconds. UTC is different from epoch time. Epoch time by definition does not count leap seconds. https://en.m.wikipedia.org/wiki/Unix_time https://en.m.wikipedia.org/wiki/Unix_time
  - zerd 10y ago
    But it is affected by leap seconds. According to the example labeled "Unix time across midnight when a UTC leap second was inserted on 1 January 1999" the unix time went backwards. So using epoch/unix time does not help.
  - EGreg 10y ago
    Is it safe to say that time() in php and Date.now() in JS do not care about leap seconds?
    - perennate 10y ago
      From [1], it is likely messier than that: > The time() function will resolve to the system time of that server. If the server is running an NTP daemon then it will be leap second aware and adjust accordingly. PHP has no knowledge of this, but the system does. > It took me a long time to understand this, but what happens is that the timestamp increases during the leap second, and when the leap second is over, the timestamp (but not the UTC!) jumps back one second. [1] http://stackoverflow.com/questions/7780464/is-time-guaranteed-to-be-leap-second-aware http://stackoverflow.com/questions/7780464/is-time-guarantee...
      - EGreg 10y ago
        It would seem much simpler to just use TAI for timestamps, and get civil datetimes from UTC. Why didn't people do this? Why use UTC for timestamps??
        rspeer 10y ago
        That doesn't seem simpler at all. - UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year. - Converting UTC timestamps to human-readable UTC times is simple modular arithmetic. A beginner in any programming language can do it. Converting TAI to UTC requires a lookup table, and it must be updated after the software is released. What would be simpler would be ending the use of leap seconds for a millennium or so.
        userbinator 10y ago
        "- UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year." Isn't it the other way around, since TAI has no leap seconds? "What would be simpler would be ending the use of leap seconds for a millennium or so." That effectively means using TAI consistently, which is what software not aware of leap seconds would be doing anyway (despite the fact that it's actually working with UTC.)
  - nshepperd 10y ago
    "Does not count leap seconds" has to win some kind of award for misleading terminology. I'd wager it's responsible for a significant portion of leap second bugs due to confusion & misunderstanding about what Unix time is: It sounds like what it means is that Unix time counts the number of real, actual, by-the-clock seconds that have passed since the epoch. That would be logical. But what it actually means is that it counts the number of real, actual, by-the-clock seconds, minus the number of those those that have been designated "leap seconds". That is to say, whenever a "leap second" occurs, the nice monotonic isotonic progress of unix time is mutilated by suddenly adding or removing 1 to the total count so far. That's what "does not count leap seconds" means, and sometimes even what "ignores leap seconds" means (which is of course even worse terminology).
    - wyager 10y ago
      Shit, you're right. It had me totally fooled.

dingaling 10y ago

And alternatively I guessed that big services like Cloudflare, responsible for fronting 2.5 million websites, would have been running a preproduction environment clocked-forward to 2017.