this post was submitted on 01 Mar 2024

135 points (97.9% liked)

Rust

5807 readers

42 users here now

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

Wormhole

[email protected]

Credits

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

founded 1 year ago

MODERATORS

[email protected]

135

Should I file a bug report? 😀 (programming.dev)

submitted 7 months ago* (last edited 7 months ago) by [email protected] to c/[email protected]

22 comments fedilink hide all child comments

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 22 comments

sorted by: hot top controversial new old

[–] Celofyz 18 points 7 months ago (3 children)

Obligatory Tom Scott's video :D https://youtu.be/-5wpm-gesOY

[–] [email protected] 11 points 7 months ago (4 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.

[–] [email protected] 4 points 7 months ago (2 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 ?

[–] [email protected] 2 points 7 months ago (1 children)

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.

[–] [email protected] 1 points 7 months ago (1 children)

I wasn't clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:

day 1: Monday morning to Tuesday evening
day 2: Tuesday morning to Wednesday evening
day 3: Wednesday morning to Thurday,
…

And phares like "let's meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let's meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.

And alternative be to have

day 1 == Monday == “end of the 19th” to “the start of the 20th”
day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
day 3 == Monday == “end of the 21st” to “the start of the 22nd”
…

Which solve the issue of "let's meet on Tuesday”, but not “let's meet the 20th”.

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago)

Yes, that's one actual problem that is not covered by everyday speech as it is in use today.

I think it would be very quickly solved by language evolution. E.g. we'd switch to something like "the evening on the 20th" or "the third day next week" (weeks are defined by the presence of weekends, just like they are today). But nonetheless it's a valid argument.

Edit: even today weekends cover multiple days. However you define a weekend now can probably be used to define a day in the global UTC system.

[–] [email protected] 2 points 7 months ago

No, I think that would still be based on local sun time, and we'd just not use it much when talking to people outside that time zone. So in a video call, we'd just say, "let's meet at 08:00", which could be "tomorrow" for some listeners, and could be later today for others. A day would still be from sun-up to sun-down, in colloquial terms, but dates would be from 00:00 to 23:59, so if you wanted to be precise, you'd just say the date.

[–] [email protected] 3 points 7 months ago

Why should we keep leap seconds? Let noon drift by 1 minute per century (or whatever).

[–] [email protected] 2 points 7 months ago (1 children)

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

[–] [email protected] 2 points 7 months ago

Ew gross... ☹️

[–] [email protected] 1 points 7 months ago

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!

[–] [email protected] 1 points 7 months ago

Here is an alternative Piped link(s):

https://piped.video/-5wpm-gesOY

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source; check me out at GitHub.

[–] [email protected] 0 points 7 months ago

Here is an alternative Piped link(s):

https://piped.video/-5wpm-gesOY

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source; check me out at GitHub.

[–] frankenswine 10 points 7 months ago

yes

yes, you should

[–] [email protected] 7 points 7 months ago* (last edited 7 months 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).

[–] [email protected] 4 points 7 months ago

Next time trying to handle a date...

[–] [email protected] 6 points 7 months ago

yes you should

[–] calcopiritus 4 points 7 months ago (1 children)

No .unwrap()? It just panics?

[–] [email protected] 3 points 7 months ago (1 children)

Might explain why the function is deprecated

[–] [email protected] 3 points 7 months ago

Yes, the new functions returns an LocalResult that is like an Option, so that didn't fail as spectacular 😃

[–] [email protected] 2 points 7 months ago

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

[–] [email protected] 2 points 7 months ago

Looks like a true case of Stockholm syndrome.