4 ms·

The following is a bit of a rant so I apologize in advance. I'm not a programmer, but I understand enough about systems administration to know why monotonic ti

The following is a bit of a rant so I apologize in advance. I'm not a programmer, but I understand enough about systems administration to know why monotonic time is important. But leap seconds exist for a reason - the rate of Earth's spin is not constant, so since the invention of clocks accurate enough to be able to tell that, we have had to invent a way of compensating for the variable rate of spin such that "midday" is still the middle of the day and "midnight" is still the middle of the night. Without adjustment, these concepts would slowly drift. It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. The definition of unix time excluding leap seconds is really the origin of this nonsense, and it has always seemed to me that the obvious solution is computers should simply measure seconds since the epoch. Wikipedia describes this version as the "TAI-based variant" of Unix Time, and if we all used it, computers wouldn't even have to care about leap seconds, and conversion to standard time display could be done in userland, accounting for leap seconds in the process. Civil time is more important than keeping your log files in order. Get your computers to count seconds, and leave more important human concepts like midday and midnight to the humans who are affected by them.

humanistbot 5y ago
> It makes me angry that programmers feel that they "own" the concept of time measurement Programmers feel that they "own" pretty much every social construct, by virtue of the fact that it is their job to encode those constructs into interfaces and databases. See the famous "falsehoods programmers believe about X" [1] --- and I'm sure you'll like this one about time [2]. [1] https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood [2] https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
shkkmo 5y ago
My understanding is that the rate of earth's spin is "constant" (actually it is slowly decreasing on geologic time scales) but the orbit of the earth is not circular and a revolution around the sun doesn't match with a full number of earth rotations.
- LeoPanthera 5y ago
  That is not correct. Positive leap seconds are caused by Earth's rotation rate slowing. Recently the Earth has begun to rotate slightly faster, possibly caused by climate change, which may mean a negative leap second is necessary. https://en.wikipedia.org/wiki/Earth%27s_rotation https://en.wikipedia.org/wiki/Earth%27s_rotation
diamondlovesyou 5y ago
> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. The definition of unix time excluding leap seconds is really the origin of this nonsense, and it has always seemed to me that the obvious solution is computers should simply measure seconds since the epoch. Wikipedia describes this version as the "TAI-based variant" of Unix Time, and if we all used it, computers wouldn't even have to care about leap seconds, and conversion to standard time display could be done in userland, accounting for leap seconds in the process. That's not fair to programmers: the definition of a leap second is up to an international organisation (IERS), and more importantly leap seconds added in 2020 couldn't have been known by anyone in the 1970s. Leap seconds are added only six months before they are to take effect, as per wiki (https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second): "Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable."
zajio1am 5y ago
> We have had to invent a way of compensating for the variable rate of spin such that "midday" is still the middle of the day and "midnight" is still the middle of the night. Just granularity of timezones causes 30min offset of civil 'midday' and 'midnight' to astronomical one (more with political borders of timezones instead of strict 15°). DST adds another 1h of offset. If we want adjustments so these concepts would not slowly drift away, we can just shift timezones once per few thousand years.
duskwuff 5y ago
> the obvious solution is computers should simply measure seconds since the epoch Obvious solutions are usually wrong, and this one is no exception. How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Since leap seconds are only announced 6 months in advance, any number you pick right now could be off by as much as 15-20 seconds in either direction. Conversely, as those leap seconds are decided upon, the human-readable representation of that number could change unpredictably.
- zajio1am 5y ago
  > How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Problem is that "January 1, 2030, midnight GMT" is not time moment itself, it is just human label for some time moment. Time is a physical quantity measurered in seconds. We do not know which time will be represented by label "January 1, 2030, midnight GMT" in the future, because that might change. That is why such representation it is unusable as a timestamp.
  - duskwuff 5y ago
    And that's ridiculous. Outside of special cases like changes to DST rules, people expect to be able to perform arithmetic on dates and get results which don't vary over time, no more than other physical measurements and operations change over time.
    - nine_k 5y ago
      As long as you can afford a half-minute precision for an event 8.5 years ahead, you still can assume that simple datetime arithmetic works. This is ignoring the complexity of the reality. If you need a better precision, you store your date as a label saying "local midnight of January 1st 2030", and adjust its mapping to a particular number of seconds since epoch as time passes, or maybe do something even more complex. This is adjusting to the complexity of the reality. The third way, mandating the reality to not be complex, is not available.
    - 5y ago
BLKNSLVR 5y ago
The feeling of "ownership" is likely the result of being the ones asked to "solve" it. Or possibly being the only group of people able to solve it in the ubiquitous software context. Provide better requirements to result in the solution you actually want.
deleted 5y ago
[deleted]
dexwiz 5y ago
No clock is perfect. Computer clocks and data types assume exactly the same amount of seconds per day. Adding leap seconds to clock code makes it unnecessarily complicated. Leap days have a well behaving algorithm, but leap seconds require a lookup to a table that changes over time. Also maybe people look at the raw data for dates. If we stored a different format, inevitably people would store both forms, and every time you programmed you would have to ask which form is it in. TAI is for things like GPS and missiles where super accurate timekeeping is crucial. Most computers are crap at keeping time and quickly drift. They make calls to central time servers that are better at time keeping, that is where the smear occurs. For most computers their normal drift is in the same order of magnitude as the smear, so it’s not noticeable. Also most distributed programs realize time stamps are not always correct, and when temporal ordering is crucial other methods are used.
bastawhiz 5y ago
> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. Your assumption of what happens with smearing isn't accurate. Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. The leap second isn't being removed at all: it's simply being applied over the course of an extended period of time rather than all at once. There's virtually no practical reason that any system needs to have a single moment where a leap second is observable. The leap second is still respected and applied. Besides the point that other commenters made about dates in the future being unrepresentable with a timestamp like you describe, it's unnecessary: systems already compute time correctly with or without leap seconds, and converting between an adjusted date and one fixed to the epoch is fast and straightforward. But moreover, what's your goal? If you're counting seconds, everything at the application layer that needs to present dates and times (and durations, and intervals) to humans then needs to be aware of every leap second. You trade one problem (date math that considers leap seconds) for another especially bad one (every date formatting library needs to have complete knowledge of leap seconds). I don't know about you, but the last thing I want is every programmer in the world needing to get leap seconds right instead of the few thousand people that maintain the runtimes and the OSs.
- weare138 5y ago
  >Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. >it's simply being applied over the course of an extended period of time rather than all at once. I don't follow, how can both be true? If we're averaging the differnce over a period of time there has to be a difference between systems that smear times and systems that don't. Obviously these different measurements will converge like at the end of a year but how do they sync otherwise?
  - duskwuff 5y ago
    The extra/missing second is averaged over the 24 hours surrounding that second. The difference in times between smearing and non-smearing systems never exceeds 500 milliseconds, and their difference in clock "speeds" is a bit under 12 ppm.
slyall 5y ago
For the majority of people solar noon does not match civil noon. Today solar noon at my location was at 12:27. If you live at the equator walking 500 metres east or west will put you a second off solar noon. That distance is reduced the further you get away from the equator. Abolishing leap seconds would be unnoticeable for the majority of the population for thousands of years. At that point it could be fixed in one go or timezones could be slowly moved. Those that would notice the change probably need sub-second accuracy that leap seconds just make more complicated.
- GranularRecipe 5y ago
  The leap second is not for majority of people, but for scientists and astronomers so that they can use UTC. Cf. https://www.nist.gov/pml/time-and-frequency-division/leap-seconds-faqs#adding https://www.nist.gov/pml/time-and-frequency-division/leap-se...

humanistbot 5y ago

> It makes me angry that programmers feel that they "own" the concept of time measurement Programmers feel that they "own" pretty much every social construct, by virtue of the fact that it is their job to encode those constructs into interfaces and databases. See the famous "falsehoods programmers believe about X" [1] --- and I'm sure you'll like this one about time [2]. [1] https://github.com/kdeldycke/awesome-falsehood https://github.com/kdeldycke/awesome-falsehood [2] https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...

shkkmo 5y ago

My understanding is that the rate of earth's spin is "constant" (actually it is slowly decreasing on geologic time scales) but the orbit of the earth is not circular and a revolution around the sun doesn't match with a full number of earth rotations.

LeoPanthera 5y ago
That is not correct. Positive leap seconds are caused by Earth's rotation rate slowing. Recently the Earth has begun to rotate slightly faster, possibly caused by climate change, which may mean a negative leap second is necessary. https://en.wikipedia.org/wiki/Earth%27s_rotation https://en.wikipedia.org/wiki/Earth%27s_rotation

diamondlovesyou 5y ago

> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. The definition of unix time excluding leap seconds is really the origin of this nonsense, and it has always seemed to me that the obvious solution is computers should simply measure seconds since the epoch. Wikipedia describes this version as the "TAI-based variant" of Unix Time, and if we all used it, computers wouldn't even have to care about leap seconds, and conversion to standard time display could be done in userland, accounting for leap seconds in the process. That's not fair to programmers: the definition of a leap second is up to an international organisation (IERS), and more importantly leap seconds added in 2020 couldn't have been known by anyone in the 1970s. Leap seconds are added only six months before they are to take effect, as per wiki (https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second): "Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable."

zajio1am 5y ago

> We have had to invent a way of compensating for the variable rate of spin such that "midday" is still the middle of the day and "midnight" is still the middle of the night. Just granularity of timezones causes 30min offset of civil 'midday' and 'midnight' to astronomical one (more with political borders of timezones instead of strict 15°). DST adds another 1h of offset. If we want adjustments so these concepts would not slowly drift away, we can just shift timezones once per few thousand years.

duskwuff 5y ago

> the obvious solution is computers should simply measure seconds since the epoch Obvious solutions are usually wrong, and this one is no exception. How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Since leap seconds are only announced 6 months in advance, any number you pick right now could be off by as much as 15-20 seconds in either direction. Conversely, as those leap seconds are decided upon, the human-readable representation of that number could change unpredictably.

zajio1am 5y ago
> How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Problem is that "January 1, 2030, midnight GMT" is not time moment itself, it is just human label for some time moment. Time is a physical quantity measurered in seconds. We do not know which time will be represented by label "January 1, 2030, midnight GMT" in the future, because that might change. That is why such representation it is unusable as a timestamp.
- duskwuff 5y ago
  And that's ridiculous. Outside of special cases like changes to DST rules, people expect to be able to perform arithmetic on dates and get results which don't vary over time, no more than other physical measurements and operations change over time.
  - nine_k 5y ago
    As long as you can afford a half-minute precision for an event 8.5 years ahead, you still can assume that simple datetime arithmetic works. This is ignoring the complexity of the reality. If you need a better precision, you store your date as a label saying "local midnight of January 1st 2030", and adjust its mapping to a particular number of seconds since epoch as time passes, or maybe do something even more complex. This is adjusting to the complexity of the reality. The third way, mandating the reality to not be complex, is not available.
  - 5y ago

BLKNSLVR 5y ago

The feeling of "ownership" is likely the result of being the ones asked to "solve" it. Or possibly being the only group of people able to solve it in the ubiquitous software context. Provide better requirements to result in the solution you actually want.

deleted 5y ago

[deleted]

dexwiz 5y ago

No clock is perfect. Computer clocks and data types assume exactly the same amount of seconds per day. Adding leap seconds to clock code makes it unnecessarily complicated. Leap days have a well behaving algorithm, but leap seconds require a lookup to a table that changes over time. Also maybe people look at the raw data for dates. If we stored a different format, inevitably people would store both forms, and every time you programmed you would have to ask which form is it in. TAI is for things like GPS and missiles where super accurate timekeeping is crucial. Most computers are crap at keeping time and quickly drift. They make calls to central time servers that are better at time keeping, that is where the smear occurs. For most computers their normal drift is in the same order of magnitude as the smear, so it’s not noticeable. Also most distributed programs realize time stamps are not always correct, and when temporal ordering is crucial other methods are used.

bastawhiz 5y ago

> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. Your assumption of what happens with smearing isn't accurate. Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. The leap second isn't being removed at all: it's simply being applied over the course of an extended period of time rather than all at once. There's virtually no practical reason that any system needs to have a single moment where a leap second is observable. The leap second is still respected and applied. Besides the point that other commenters made about dates in the future being unrepresentable with a timestamp like you describe, it's unnecessary: systems already compute time correctly with or without leap seconds, and converting between an adjusted date and one fixed to the epoch is fast and straightforward. But moreover, what's your goal? If you're counting seconds, everything at the application layer that needs to present dates and times (and durations, and intervals) to humans then needs to be aware of every leap second. You trade one problem (date math that considers leap seconds) for another especially bad one (every date formatting library needs to have complete knowledge of leap seconds). I don't know about you, but the last thing I want is every programmer in the world needing to get leap seconds right instead of the few thousand people that maintain the runtimes and the OSs.

weare138 5y ago
>Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. >it's simply being applied over the course of an extended period of time rather than all at once. I don't follow, how can both be true? If we're averaging the differnce over a period of time there has to be a difference between systems that smear times and systems that don't. Obviously these different measurements will converge like at the end of a year but how do they sync otherwise?
- duskwuff 5y ago
  The extra/missing second is averaged over the 24 hours surrounding that second. The difference in times between smearing and non-smearing systems never exceeds 500 milliseconds, and their difference in clock "speeds" is a bit under 12 ppm.

slyall 5y ago

For the majority of people solar noon does not match civil noon. Today solar noon at my location was at 12:27. If you live at the equator walking 500 metres east or west will put you a second off solar noon. That distance is reduced the further you get away from the equator. Abolishing leap seconds would be unnoticeable for the majority of the population for thousands of years. At that point it could be fixed in one go or timezones could be slowly moved. Those that would notice the change probably need sub-second accuracy that leap seconds just make more complicated.

GranularRecipe 5y ago
The leap second is not for majority of people, but for scientists and astronomers so that they can use UTC. Cf. https://www.nist.gov/pml/time-and-frequency-division/leap-seconds-faqs#adding https://www.nist.gov/pml/time-and-frequency-division/leap-se...