Live data from Hacker News

The leap second’s time is up: world votes to stop pausing clocks

nature.com

391–400 of 456 posts

Re: The leap second’s time is up: world votes to stop pausing clocks

#392
post #189
post #115

Earlier 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...

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.

Re: The leap second’s time is up: world votes to stop pausing clocks

#393
post #189

Earlier 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.

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

Re: The leap second’s time is up: world votes to stop pausing clocks

#394
post #382

Earlier 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

Postgres supports timezones. In general Postgres is excellent for correctness at the cost of performance.

Re: The leap second’s time is up: world votes to stop pausing clocks

#395
post #379
post #345

Earlier 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.

That's the problem though. If you don't support the durations that nobody uses, then you can't fully support ISO8601 dates.

Every trivial variation is another if/switch statement.

Re: The leap second’s time is up: world votes to stop pausing clocks

#396
post #144

Earlier 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…

I don’t think that’s right. I would think the effect of melt of glaciers on mountains would be negligible and the effect of the poles melting and sending that water down to the poles would slow down rotation, like an ice skater pushing their arms out.

Re: The leap second’s time is up: world votes to stop pausing clocks

#397

Earlier 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…

... what if we switched to leap milliseconds?

Re: The leap second’s time is up: world votes to stop pausing clocks

#398

Earlier 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.

That doesn't answer my question. What I mean is that "a day" is not a fixed length, but depends on the existence of leap seconds. Most days have 246060 seconds, but not all.

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

#399

Earlier 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

The hardware providing those nanoseconds is not nanosecond accurate (unless using atomic clock)

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

#400
post #382

Earlier 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

Europe/Berlin is NOT an offset, it's the zone. A proper date needs BOTH the offset AND the zone ! How come people don't understand timezone when it's right there, in the etymology of the word !?

Sorry not personal but I find myself explaining that each time the subject comes up at work (and generally to the same people... sigh)

Post reply on HN