undefined | Better HN

0 pointsyreg3y ago0 comments

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

0 comments

codetrotter3y ago

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

3pt141593y ago

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

geenew3y ago

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

tim--3y ago

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

2 more replies

afiori3y ago

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

ldng3y ago

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)

rjh293y ago

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

leni5363y ago

unix timestemp is unaffected by DST

int_19h3y ago

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

Affric3y ago

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

j / k navigate · click thread line to collapse