5 ms·

It's not just a headsche for Meta's programmers. Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with. Every six months

It's not just a headsche for Meta's programmers. Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with. Every six months is simply too often. If it was switched to an adjustment made every 2-10 decades with at least a decade to update the file then the problem would be greatly lessened.

aeyes 4y ago
Why is this too often? We already need to update tzdata continuously. The problem is that it is not often enough to force you to have a good process in place.
- vbezhenar 4y ago
  So another option is to adjust to 1/100 second every few months, so good processes will have to appear, one way or another.
  - nullc 4y ago
    > So another option is to adjust to 1/100 second every few months That's pretty awful. We have a lot of systems now which care about duration. Any scheme that makes a time span unpredictable will cause problems. Doing it more often means more problems. The only improvement is that you hope that the things that care about 1/100th of a second differences are rare enough that disturbing thing many times more often is a good tradeoff. This isn't a good bet especially because at time goes on we build faster and more stable systems that care about tighter and tighter synchronization.
- willis936 4y ago
  Because tzdata is based off of political boundaries and decisions. If I'm making a dataset that needs continuous timestamps for multiple decades then UTC is effectively off the table because of how under-specified and poorly implemented leap seconds are in various software. So what's left is TAI and GPS, fine enough but now users see the timestamped data as being several seconds off. So we use a translation layer but some HMIs don't allow that so it's best to just not do it at all. This reality is not unique. Thousands of engineers have walked down this path and asked "why?".
gmiller123456 4y ago
It isn't every six months, the Earth doesn't rotate that regularly. They are introduced "at most" every 6 months, but usually far less. There have been 27 leap seconds since 1972, so less than one a year.
- msbarnett 4y ago
  27, not 37
  - gmiller123456 4y ago
    Thanks, I corrected it.
  - deleted 4y ago
    [deleted]
msbarnett 4y ago
> Every six months is simply too often. If it was switched to an adjustment made every 2-10 decades with at least a decade to update the file then the problem would be greatly lessened. You seem confused. It doesn't happen every 6 months, it gets announced 6 months in advance – since we know there won't be one this year, it will have only happened twice total in the 10 years prior to December this year. That's hardly an enormous and constant disruption – turning it in to a multi-minute disruption "every 10 decades" would likely be more concentratedly disruptive, leading to more calls to put it off to avoid the immediate pain, leading to ever-more accumulated error. Spreading the pain out into a leap second every few years feels like a much better and more sustainable solution. This keeps processes in-use and up-to-date rather than long-forgotten-and-everyone-who-knew-them-is-dead.
- ncmncm 4y ago
  I guess you also brush 3 teeth in each of 11 interruptions thoughout your day, and again all night.
  - aftbit 4y ago
    I guess you brush your teeth for one hour once a month.
    - ncmncm 4y ago
      You miss the point again. Don't give up. You will get there in the end.
- deleted 4y ago
  [deleted]
- BurningFrog 4y ago
  It's moved 7 seconds the last 25 years, so over 10 decades it should be about 28 seconds, not a multi-minute disruption. Source: https://endruntechnologies.com/support/leap-seconds https://endruntechnologies.com/support/leap-seconds
hannasanarion 4y ago
Palestine switched off Daylight Saving Time this year with only 4 days notice. Anyone involved with bookkeeping and synchronizing should already know to never attempt to handle time conversions using your own program logic updated by hand, because the definition of time is constantly changing and there are already projects like tzdata dedicated to centralizing the handling of it. There have already been 5 time zone updates this year, 4 changes to the date that Palestine switches daylight savings (one of them with only four days notice!) and Fiji decided to quit using daylight saving time, plus the Leap Second announced on July 9.
- yyyk 4y ago
  Reminds me of this story: https://darwinawards.com/darwin/darwin1999-38.html https://darwinawards.com/darwin/darwin1999-38.html
- alerighi 4y ago
  That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend on the particular timezone. So it's less of a problem, since at lower levels you don't have the concept of timezone (you may never have it, for example on embedded devices). But if UTC shifts, it's another story. You assume the UTC (or UNIX) time to be a monotonic counter, and usually it's used this way, for example you compare two timestamps to know what definitively happened before another thing. Surely you don't take into account leap seconds... this is the problem. Leap seconds wouldn't be that much of an issue if the time is only increased, you have one more second, it's the higher level implementation that has the concept of time to (maybe) deal with it. But they become an issue if they can take behind the UTC clock since it can generate all sort of strange bugs. It's even a worse solution to make the duration of a second in a day longer or shorted, because you preserve the counter value, but you no longer can rely on the fact of 1 seconds being 1000ms long! By the way the concept of leap second is nonsense to me. What is the purpose? If the purpose is to keep in sync the time with the rotation of the earth, nobody will ever notice an error of a couple of seconds, or even minutes. It makes more sense to take the current definition of a second, and then wait till the error is noticeable to an human being (let's say an error of 15 minutes, that would take centuries and we will probably far gone from the planet) and adjust it by shifting all the timezone for that amount of time.
MikePlacid 4y ago
> Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with. It is unnecessary but not because of leap seconds which are the phenomenon of real life, not some abstract invention of astronomers. The unnecessary bugbear is caused by a wrong time system design. We need both the atomic time (which corresponds to number of quartz pulses elapsed since some fixed moment in the past), and the astronomy time (which represents the orientation of the Earth in space). The decision to mix them up was wrong and is exactly what causing “the unnecessary bugbear”. Do not want the bugbear - fix the cause of the problem.
denton-scratch 4y ago
> then the problem would be greatly lessened. I disagree; I think it would be made worse. UTC timekeeping in computers depends on a database of leapseconds, which has to be updated. But many systems don't get updated, resulting in drift. If leap-[seconds|minutes] only occur every 2 decades, many systems will ship with no update mechanism, on the principle "Don't worry, the system will be obsolete before twenty years is up". Hah! Famous last words.

aeyes 4y ago

Why is this too often? We already need to update tzdata continuously. The problem is that it is not often enough to force you to have a good process in place.

vbezhenar 4y ago
So another option is to adjust to 1/100 second every few months, so good processes will have to appear, one way or another.
- nullc 4y ago
  > So another option is to adjust to 1/100 second every few months That's pretty awful. We have a lot of systems now which care about duration. Any scheme that makes a time span unpredictable will cause problems. Doing it more often means more problems. The only improvement is that you hope that the things that care about 1/100th of a second differences are rare enough that disturbing thing many times more often is a good tradeoff. This isn't a good bet especially because at time goes on we build faster and more stable systems that care about tighter and tighter synchronization.
willis936 4y ago
Because tzdata is based off of political boundaries and decisions. If I'm making a dataset that needs continuous timestamps for multiple decades then UTC is effectively off the table because of how under-specified and poorly implemented leap seconds are in various software. So what's left is TAI and GPS, fine enough but now users see the timestamped data as being several seconds off. So we use a translation layer but some HMIs don't allow that so it's best to just not do it at all. This reality is not unique. Thousands of engineers have walked down this path and asked "why?".

gmiller123456 4y ago

It isn't every six months, the Earth doesn't rotate that regularly. They are introduced "at most" every 6 months, but usually far less. There have been 27 leap seconds since 1972, so less than one a year.

msbarnett 4y ago
27, not 37
- gmiller123456 4y ago
  Thanks, I corrected it.
- deleted 4y ago
  [deleted]

msbarnett 4y ago

> Every six months is simply too often. If it was switched to an adjustment made every 2-10 decades with at least a decade to update the file then the problem would be greatly lessened. You seem confused. It doesn't happen every 6 months, it gets announced 6 months in advance – since we know there won't be one this year, it will have only happened twice total in the 10 years prior to December this year. That's hardly an enormous and constant disruption – turning it in to a multi-minute disruption "every 10 decades" would likely be more concentratedly disruptive, leading to more calls to put it off to avoid the immediate pain, leading to ever-more accumulated error. Spreading the pain out into a leap second every few years feels like a much better and more sustainable solution. This keeps processes in-use and up-to-date rather than long-forgotten-and-everyone-who-knew-them-is-dead.

ncmncm 4y ago
I guess you also brush 3 teeth in each of 11 interruptions thoughout your day, and again all night.
- aftbit 4y ago
  I guess you brush your teeth for one hour once a month.
  - ncmncm 4y ago
    You miss the point again. Don't give up. You will get there in the end.
deleted 4y ago
[deleted]
BurningFrog 4y ago
It's moved 7 seconds the last 25 years, so over 10 decades it should be about 28 seconds, not a multi-minute disruption. Source: https://endruntechnologies.com/support/leap-seconds https://endruntechnologies.com/support/leap-seconds

hannasanarion 4y ago

Palestine switched off Daylight Saving Time this year with only 4 days notice. Anyone involved with bookkeeping and synchronizing should already know to never attempt to handle time conversions using your own program logic updated by hand, because the definition of time is constantly changing and there are already projects like tzdata dedicated to centralizing the handling of it. There have already been 5 time zone updates this year, 4 changes to the date that Palestine switches daylight savings (one of them with only four days notice!) and Fiji decided to quit using daylight saving time, plus the Leap Second announced on July 9.

yyyk 4y ago
Reminds me of this story: https://darwinawards.com/darwin/darwin1999-38.html https://darwinawards.com/darwin/darwin1999-38.html
alerighi 4y ago
That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend on the particular timezone. So it's less of a problem, since at lower levels you don't have the concept of timezone (you may never have it, for example on embedded devices). But if UTC shifts, it's another story. You assume the UTC (or UNIX) time to be a monotonic counter, and usually it's used this way, for example you compare two timestamps to know what definitively happened before another thing. Surely you don't take into account leap seconds... this is the problem. Leap seconds wouldn't be that much of an issue if the time is only increased, you have one more second, it's the higher level implementation that has the concept of time to (maybe) deal with it. But they become an issue if they can take behind the UTC clock since it can generate all sort of strange bugs. It's even a worse solution to make the duration of a second in a day longer or shorted, because you preserve the counter value, but you no longer can rely on the fact of 1 seconds being 1000ms long! By the way the concept of leap second is nonsense to me. What is the purpose? If the purpose is to keep in sync the time with the rotation of the earth, nobody will ever notice an error of a couple of seconds, or even minutes. It makes more sense to take the current definition of a second, and then wait till the error is noticeable to an human being (let's say an error of 15 minutes, that would take centuries and we will probably far gone from the planet) and adjust it by shifting all the timezone for that amount of time.

MikePlacid 4y ago

> Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with. It is unnecessary but not because of leap seconds which are the phenomenon of real life, not some abstract invention of astronomers. The unnecessary bugbear is caused by a wrong time system design. We need both the atomic time (which corresponds to number of quartz pulses elapsed since some fixed moment in the past), and the astronomy time (which represents the orientation of the Earth in space). The decision to mix them up was wrong and is exactly what causing “the unnecessary bugbear”. Do not want the bugbear - fix the cause of the problem.

denton-scratch 4y ago

> then the problem would be greatly lessened. I disagree; I think it would be made worse. UTC timekeeping in computers depends on a database of leapseconds, which has to be updated. But many systems don't get updated, resulting in drift. If leap-[seconds|minutes] only occur every 2 decades, many systems will ship with no update mechanism, on the principle "Don't worry, the system will be obsolete before twenty years is up". Hah! Famous last words.