- cross-posted to:
- programmer_humor@programming.dev
- cross-posted to:
- programmer_humor@programming.dev
TIL: Sweden had February 30 in 1712 https://en.wikipedia.org/wiki/1712_in_Sweden , so I decided to see how chrono handled that.
use chrono::TimeZone;
use chrono_tz::Europe::Stockholm;
fn main() {
let feb30 = Stockholm.ymd(1712,2,30);
println!("Date: {:?}", feb30);
}
target/debug/feb30
thread 'main' panicked at /home/snaggen/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chrono-0.4.34/src/offset/mod.rs:252:40:
No such local time
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Result (as expected): Not well! 😄
I also tested Java with
ZonedDateTime feb30 = ZonedDateTime.of(1712,2,30, 0,0,0,0, ZoneId.of("Europe/Stockholm"));
with simmilar result
java.time.DateTimeException: Invalid date 'FEBRUARY 30'
So, lets take a minute of silence for all the programmers of history related software, may the spagetti monster have mercy on their souls.
Obligatory Tom Scott’s video :D https://youtu.be/-5wpm-gesOY
Even just sticking with UNIX timestamps and relying on a library, dealing with time zones still sucks. Inevitably, your backend and frontend libraries will have some difference in some case that matters for some customer. And it won’t happen just after release, but some months down the road when one country somewhere changes their laws and your libraries don’t get updated in time, or maybe there’s a bug like in the OP.
Madness lies everywhere when talking about time.
We should all do ourselves a favor and follow UTC time everywhere. There’s still leap seconds and leap days to deal with, but so many problems just disappear if everyone uses the same time. The sun may come up at 20:00 and go down at 09:00, but your stores can just adjust their hours and it’s totally fine. You won’t ever have to worry about missing a meeting because the organizer’s software and yours got out of sync, and you’ll never have to mentally convert times on a call.
It’s a small price to pay, but for all our sanity, just use UTC time.
The issue is that the notion of “tomorrow” becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?
Most people are flexible about that already. If you stay up to ten past twelve, do you say “I really need to get to bed now, I have work tomorrow” or do you say “I really need to get to bed now, I have work today”?
The same will be true for morning and evening in everyday speech, it follows your sleep schedule, which follows the sun. Just like summer can already mean July or December, depending on your longitude.