this post was submitted on 01 Mar 2024
124 points (98.4% liked)

Rust

7232 readers
12 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 2 years ago
MODERATORS
 

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.

top 15 comments
sorted by: hot top controversial new old
[–] TehPers@beehaw.org 36 points 1 year ago* (last edited 1 year ago) (1 children)

I know you're joking about the bug report, but you could open an issue about it anyway if it genuinely is a thing. I did a quick search though and it looks like it was a transition period between two different calendars. Maybe chrono intentionally assumes Gregorian calendar, or some simplified version of it at least?

Edit: found this in chrono's readme:

Only the proleptic Gregorian calendar (i.e. extended to support older dates) is supported.

I wouldn't open an issue actually since this is specifically called out already.

[–] snaggen@programming.dev 10 points 1 year ago* (last edited 1 year ago)

I think there are so much issues with historical dates, that it is probably not worth fixing it in general purpose libraries. Not only do you need to special case everything like this in relation to dates, but you would also need to keep track of all historical territories (like Prussia and such) and what was part of what. In this particular case, I think that the timezone Europe::Helsinki was part of Sweden and should be included (possibly some cities from current Poland). There is no need to add that kind of complexity to general purpose libraries, that should probably be in some special historical date / region library if needed.

Also, there was not really a concept of time zones before the railway, then the time was floating. The time was not the same in the whole country, because that was not a problem before people started to travel faster and in a way that needed time tables. So, that also fits poorly in a modern general purpose date/time library.

[–] Celofyz@lemmy.world 16 points 1 year ago (1 children)
[–] sugar_in_your_tea@sh.itjust.works 1 points 1 year ago (1 children)

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.

[–] robinm@programming.dev 0 points 1 year ago (1 children)

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 ?

[–] Turun@feddit.de 1 points 1 year ago

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.

[–] frankenswine@lemmy.world 8 points 1 year ago

yes

yes, you should

[–] Vorpal@programming.dev 7 points 1 year ago* (last edited 1 year ago) (1 children)

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

Next time trying to handle a date...

yes you should

[–] calcopiritus@lemmy.world 3 points 1 year ago (1 children)

No .unwrap()? It just panics?

[–] Miaou@jlai.lu 2 points 1 year ago (1 children)

Might explain why the function is deprecated

[–] snaggen@programming.dev 2 points 1 year ago

Yes, the new functions returns an LocalResult that is like an Option, so that didn't fail as spectacular πŸ˜ƒ

[–] TypicalHog@lemm.ee 2 points 1 year ago

OMG why did they have FEB 30th? That seems cursed and unbased AF.

[–] arendjr@programming.dev 2 points 1 year ago

Looks like a true case of Stockholm syndrome.