The leap second’s time is up: world votes to stop pausing clocks
391–400 of 456 posts
Re: The leap second’s time is up: world votes to stop pausing clocks
#392Earlier quoted context omitted.
Reminds me of the story of the computer engineer at Data General in Traccy Kidder's nonficion book, "The Soul of a New Machine" [0], who quit after spending weeks toiling away on sub-second timing concerns: > He went away from the basement and left this note on his terminal: "I'm going to a commune in Vermont and will deal with no unit of time shorter than a season." [0] https://en.m.wikipedia.org/wiki/The_Soul_of_a_…
What should I say, trying to go sub millisecond, one profiling run at a time, sigh...
With busy waiting, you can achieve timings in the sub-microsecond range, depending on how heavy the loop is.
Re: The leap second’s time is up: world votes to stop pausing clocks
#393Earlier quoted context omitted.
What should I say, trying to go sub millisecond, one profiling run at a time, sigh...
Sub millisecond timing is basically impossible with context switching involved. Even on a real time kernel config, the best you are going to get with a time slice is 1ms. With busy waiting, you can achieve timings in the sub-microsecond range, depending on how heavy the loop is.
Key words: constant TSC, invariant TSC, TSC clocksource
Re: The leap second’s time is up: world votes to stop pausing clocks
#394Earlier quoted context omitted.
The interesting thing about DST is that it's not really repeating the hour, if you include the time zone offset in your time stamp. Here, look. Using the time zone for Norway in this example, with the `date` command on macOS. First the last second before DST ended in Norway this year. TZ=Europe/Oslo date -I seconds -jf %s 1667091599 2022-10-30T02:59:59+02:00 Then the second after. TZ=Europe/Oslo date -I seconds -jf %…
The problem is that nobody does it, for example no DB (AFAIK) does it, they all store dates as something like a Unix timestamp. And for a lot of things problems would be solved with +01:00 offset while for others you actually want Europe/Berlin offsets
Re: The leap second’s time is up: world votes to stop pausing clocks
#395Earlier quoted context omitted.
This is a misconception. ISO8601 has six versions, is 14 pages long, and defines way to many ways to represent dates and times. Everyone should follow RFC 3339. https://www.rfc-editor.org/rfc/rfc3339#section-5.6
But they‘re mostly trivial variations of each other, or durations that nobody uses at all.
Every trivial variation is another if/switch statement.
Re: The leap second’s time is up: world votes to stop pausing clocks
#396Earlier quoted context omitted.
You're right, but I'd argue this problem is already here. Thanks to glaciers melting, earth rotation is (temporarily) accelerating. Because of that, positive leap seconds, regular before, didn't happen since 2017 - so there could very well be (recent) software out there that has that code-path broken, and nobody noticed yet. And due to exact same geophysical effect we might see a negative leap second - something that…
Interesting point. Just like a skater pulling their arms in, snow melting and running to lower ground would make the earth spin faster (and let's add in the extra erosion). Sea levels are rising though (due to both thermal expansion and runoff). Be interesting to estimate the size of the various effects (no doubt I've missed plenty of others) but is it really true that a change in sign of the acceleration of Earth's…
Re: The leap second’s time is up: world votes to stop pausing clocks
#397Earlier quoted context omitted.
Great, here's another. $work had thousands of full custom, dsp-heavy, location measurement hardware devices widely deployed in the field for UTDOA locating cell phones. It used GPS for time reference -- if you know your location, you can get GPS time accurate around the 10's of nanoseconds. GPS also broadcasts a periodic almanac which includes leap second offsets: if you wanted to apply the offset to GPS you could de…
It seems the less likely an event is to occur, the less likely your vendor put work into handling it. This recalls perhaps the biggest mistake in the GPS specification, the 1024-week rollover period. A timespan long enough to be impractical to test without expensive simulator hardware, short enough to be virtually guaranteed to cause problems in long-term installations... and long enough for OEMs to ignore with impun…
Re: The leap second’s time is up: world votes to stop pausing clocks
#398Earlier quoted context omitted.
> we should be using TAI for all [...] computation How do you add a full day, if you do not know whether a leap second occured or not?
The same way you add a full year without knowing if a country will change timezones or vote to drop daylight savings: you distinguish between timestamps and calendar dates, and keep updated your timezone/leap second database.
Say I have a timestamp in the future, and I want to add a day to this. Then the first approximation would be to add 246060 seconds. However if there occurs a leap second in that day, the correct thing is to add one more second. But I do not necessarily know today, if there will be a leap second. So I cannot compute the correct timestamp.
Re: The leap second’s time is up: world votes to stop pausing clocks
#399Earlier quoted context omitted.
Sub millisecond timing is basically impossible with context switching involved. Even on a real time kernel config, the best you are going to get with a time slice is 1ms. With busy waiting, you can achieve timings in the sub-microsecond range, depending on how heavy the loop is.
Not sure what you mean by that but nanosecond precise timing across cpu cores have been reliable for quite a while now. Key words: constant TSC, invariant TSC, TSC clocksource
However they may be more accurate than 1ms. The guy is saying the timeslice given by the OS for a program to run in has at best a 1ms slot because the OS is switching between threads on a 1ms timeslice basis
So unless you're polling, the timing at which you ask the hardware for nanoseconds will jitter with 1ms offsets
Re: The leap second’s time is up: world votes to stop pausing clocks
#400Earlier quoted context omitted.
The interesting thing about DST is that it's not really repeating the hour, if you include the time zone offset in your time stamp. Here, look. Using the time zone for Norway in this example, with the `date` command on macOS. First the last second before DST ended in Norway this year. TZ=Europe/Oslo date -I seconds -jf %s 1667091599 2022-10-30T02:59:59+02:00 Then the second after. TZ=Europe/Oslo date -I seconds -jf %…
The problem is that nobody does it, for example no DB (AFAIK) does it, they all store dates as something like a Unix timestamp. And for a lot of things problems would be solved with +01:00 offset while for others you actually want Europe/Berlin offsets
Sorry not personal but I find myself explaining that each time the subject comes up at work (and generally to the same people... sigh)