3 ms·
>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
by yreg 4y ago
>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 4y agoThe 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 :)
- Affric 4y agoDepends on implementation. Agree that epoch makes the most sense.
- geenew 4y agoPerhaps another moral to add: ISO8601 solves a lot of problems.
- tim-- 4y agoThis 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 https://www.rfc-editor.org/rfc/rfc3339#section-5.6
- geenew 4y agoThanks! Wasn't aware of that spec.
- db48x 4y agoBut they‘re mostly trivial variations of each other, or durations that nobody uses at all.
- tim-- 4y agoThat'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 4y agoDurations are not used in places that need a timestamp, and visa versa. More applications need timestamps than need durations.
- 3pt14159 4y agoYes, but not every logger, db, etc is going to include the timezone. What they did was the right call for the situation.
- afiori 4y agoThe 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
- rjh29 4y agoPostgres supports timezones. In general Postgres is excellent for correctness at the cost of performance.
- ldng 4y agoEurope/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)
- leni536 4y agounix timestemp is unaffected by DST
- int_19h 4y agoPostgres and Oracle has TIMESTAMP WITH TIME ZONE. MSSQL has DateTimeOffset.