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
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.
I worked on a legacy application that was built in the 90s that implemented time zones by taking the Unix timestamp at eastern time and then added or subtracted the minutes needed to represent that time zone. shudder
In before someone links the horrible "so you want to abolish timezones" article, lol. It's arguing in bad faith, and yet it still gets linked every time!
Yes, Sweden really screwed up the first attempt at switching to Gregorian calendar. But there were also multiple countries who switched back and forth a couple of times. Or Switzerland where each administrative region switched separately.
But I think we in Sweden still "win" for worst screw up. Also, there is no good way to handle these dates without specific reference to precise location and which calender they refer to (timestamps will be ambiguous when switching back to Julian calendar).