Hacker News Reader

Comment by divbzero | Hacker News Reader

This is a good story regardless, but if you do want to derive some morals from the experience:

– Seemingly simple tasks can be more complex than you expect (“add a leap second on this Wednesday”)

– Real world systems can be more complex than you expect (“bunch of software I never even knew existed”)

– Planning and testing can make a big difference vs. just winging it (“a bunch of our Linux servers had kernel panics for some reason”)

– Success can be a non-event that goes unnoticed (”everything worked and no money went missing”)

– Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)

View on HN

>Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)

We've had an election recently, right on the day when DST changed. On the night of counting of the votes, the clock went 2:59 AM -> 2:00 AM.

To save themselves trouble the Statistics Office instructed all vote counters that under no circumstances are they to enter or update anything in any system during the repeating hour until it's 3:00 AM the second time…

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 %s 1667091600

    2022-10-30T02:00:00+01:00

So while people say that time went from 02:59:59 to 02:00:00, I see it as time going from 02:59:59+02:00 to 02:00:00+01:00 :)

Yes, but not every logger, db, etc is going to include the timezone. What they did was the right call for the situation.

Perhaps another moral to add: ISO8601 solves a lot of problems.

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

Thanks! Wasn't aware of that spec.

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.

Durations are not used in places that need a timestamp, and visa versa. More applications need timestamps than need durations.

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)

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

unix timestemp is unaffected by DST

Postgres and Oracle has TIMESTAMP WITH TIME ZONE. MSSQL has DateTimeOffset.

Depends on implementation. Agree that epoch makes the most sense.

> Sometimes the best solution is not a technical solution

I once came across an early 1950s Scientific American article by Bertrand Russel, IIRC. It included a cartoon.

Frame one: Computer beats man at chess.

Frame two: Man unplugs computer.

How about this? Frame one: man beats woman at chess. Frame two: woman shoots man with automatic pistol. Not sure how deep the original really is if you think about it...

The problem is you are trying to make something "deep" when it wasn't trying to be

IIRC, Russel's thesis was something to the effect of ultimate supremecy of man over machine. I associate "Sept 1952" as the issue. The last frame suggested a certain obviousness and nonchalance in the man unplugging the computer, as if no great debate would be involved. I wonder if the article itself might now evidence too much of innocence back in that day, aside from a prediction that computers would eventually beat humans at chess. Too much innocence regarding technological imperitives and the technosphere?

What?! That's not comparable at all. The computer isn't murdered, it's just off. Also even if you did destroy the computer, that's not murder.

It's not comparable because computers are things but women are not.

My intention was for the woman to shoot the man, it's possible I wrote it wrong. They could be both men or aliens or even computers/robots with human like intelligence. If they were both thinking computers the "pistol" could really be a human paid in Monero to go smash the other computers hard drives and backups.

– Success can be a non-event that goes unnoticed (”everything worked and no money went missing”)

And yet, there are still Y2K deniers (to be fair some people have exaggerated it to the point that they're promoting it as the end of the world).

> Sometimes the best solution is not a technical solution (“halt the markets for 15 minutes before/after”)

I'm little confused. How does this solve the problem? If you don't code for the second, you'll still be off if you wait. I'm I missing something?

The code to keep your clock in sync is "easy".

They had done it all the previous leap second during the weekend.

The hard part that required a lot of work was making sure that nothing breaks when it happens.

In this case they chose to have a mini weekend in the middle of the week for convenience

Reply on news.ycombinator.com