[yreg]

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

[codetrotter]

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 :)

[3pt14159]

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

[geenew]

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

[tim--]

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

[geenew]

Thanks! Wasn't aware of that spec.

[db48x]

But they‘re mostly trivial variations of each other, or durations that nobody uses at all.

[tim--]

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.

[db48x]

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

[afiori]

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

[ldng]

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)

[rjh29]

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

[leni536]

unix timestemp is unaffected by DST

[int_19h]

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

[Affric]

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