Mandating UTC everywhere and eliminating the concept of time zones altogether is all a political candidate needs to do in order to earn my vote in 2024.
Seriously, what is the point of time zones? The only explanation I’ve ever heard is “well if we didn’t have time zones, half the world would be expected to be awake when it’s dark out!” No. We could all just literally adjust the times of our business operations based around when daylight is usual for the different geographic regions as they have the sun shine on them. The physical “zones” of time zones could remain the same, and in those zones “noon” would just mean something other than “12:00.” “Noon” for one region could be 2300 while what is considered “noon” for another region could be 1800.
(And for my next rant: why the 24 hour clock is superior to the 12 hour clock… reason number 1? There’s 24 hours in a day…)
Instead of store hours like this:
- Monday 6:00-18:00
- Tuesday 6:00-18:00
- Wednesday 8:00-18:00
- Thursday 6:00-18:00
- Friday 6:00-18:00
We can have store hours like this:
- Sunday 22:00-Monday 10:00
- Monday 22:00-Tuesday 10:00
- Wednesday 0:00-10:00
- Wednesday 22:00-Thursday 10:00
- Thursday 22:00- Friday 10:00
Boy, I would love to live in a place where store hours would be like this. So convenient.
And I’d love to have the change in the day be sometime in the middle of the day so that “see you tomorrow” means sometime later in the day. Or maybe different areas would use different conventions to refer to the time when the sun is out and most people are doing things and the time when most people are asleep.
It would also be so pleasant and relaxing to visit a new country and constantly have to calculate the country’s time offset in my head. There would probably be an app on my phone that I would constantly look at that would convert the time where I am to the equivalent time I am used to. I won’t have a sense of when meals are or when I should expect stores to be open, or when it’s reasonable to wake up without converting to the time I’m used to. Some might say the thing I’m used to is my time “zone”.
It would also be great for TV shows and books to always run into issues when talking about the time because there’s no universal reference.
Even the actual convenience of scheduling a meeting with people in different parts of the world has issues. Now, you know that whatever time you say is the time for all people. But instead of being able to just look up each person’s time zone and see “oh, it would be 3am there, so they’d be asleep”, you’d have to go to some website that tells you what time most people sleep or what time most people eat meals, or whatever, and see by how many hours it differs.
You already have an entire vocabulary for solar time (sunrise, morning, noon, evening, sunset, night, midnight). This being all of a sudden assigned to a different time on a clock does not change things in any dramatic fashion. It would also be a consistent change for your current location, guarantee it only takes you less than a work week to acclimate.
All the things you’ve described I’ve literally been doing for 6 months now. It is not a noticable difference and does not impact me.
Also, a book that says “it was 5 o’clock” is objectively more boring than one that describes the shadows of twilight blanketing the scene in a checkering of shadow. Also TV shows show outside, where solar time is visibly apparent. The specific time is not nearly as relevant.
Also, you already look up time zones when scheduling international meetings, and those aren’t going to tell you about siestas or other local practices which might affect scheduling. Maybe just actually ask the person what times will work when trying to schedule, and now since you’re both using UTC, you both can figure it out together without looking up timezones.
Or, ooor, the obvious answer of mandating the UTC in the backend.
Actually moving societies all to UTC is a really bad idea, as outlined by many others, dozens of times on Lemmy.
24 hour time though, that’d be nice. Everyone already knows how it works anyway!
Anything an API returns should just look like
1720533944.963659.There’s no reason to store dates as anything other than UTC. User-side, sure, timezones are useful. Server doesn’t have to know.
deleted by creator
So just for additional context:
This meme was brought to you by the following API response scheme:
{ "time": "2007-12-24 18:12", "servertimezone": "Europe/Vienna", "timezoneoffset": -8 }when it could have just been
{ "date": "2007-12-24T18:21:00-07:00" }To be fair, returning the actual timezone (as defined by tz.db) is useful if you don’t just want the current time since you’ll be able to take DST into account. Not sure how Vienna is -8 though, it should be +1 (or 2 depending on DST).
Just for further clarification, the API works like this:
timeis the local (client) time (in this case UTC-7)servertimezoneis the time zone where the server is locatedtimezoneoffsetis the offset of the local time relative to the servertimezone (offset from the servers PoV)
To get the UTC date you have to do something like this:
time.minusHours(timezoneoffset).atZone(servertimezone).toUTC()Your comment is a full throated endorsement of just working in UTC up until the presentation layer. Whether you intended that or not is another question.
It is? Without even mentioning it?
To be clear I believe it makes sense to do a lot of things in UTC, but future events should almost always be local time + timezone to make scheduling predictable and consistent to humans.
Yes. Not intentionally of course. But yes.
I don’t see how your way is any more predictable or consistent than using UTC. What even is “local time”? Are you assuming they haven’t changed timezone since they created the data? Say…DST happened, or they drove over a border…?
Storing and manipulating in UTC is the most predictable and consistent because it is universal and unchanging. You only need to worry about “local time” at the point of displaying it.
We have slackbots that post, for instance, who has vecation every day. Because it is configured to post this using UTC, the time of day this is posted changes twice a year.
I might have a recurring appointment for lunch in my calendar every day at noon. Now DST happened, so I have to wait until one to eat. That is inconsistent to me.
Timezones change. If I have to go to the theatre on half a year at 18:00, I don’t want to be there at 19:00 because someone decided local time would be better if we moved it an hour. The show time certainly won’t be moved.
What is local time? It’s spacetime. When did it happen and if relevant (eg. a photo) what was the offset (because I would like to know the time of day)? When will it happen, and where? Online meetings across timezones are tricky, of course, but excluding the timezone won’t improve that.
It should’ve been unix timestamp
Never not UTC Everywhere.
UTC is better than most, but leap seconds are still awful. Computers should use GPS or TAI everywhere. Dealing with time zones and leap seconds is for human readability and display purposes only.
That’s why I only ever use Seconds Since Epoch.
There’s an even worse thing: timezone selection UIs that don’t let you choose UTC
There is one big caveat to universal time:
Future dates: If you use utc here and a time zone definition changes, you’re boned. You have to store local time and offset for just this one usecase.
Sorry, why would you be “boned” if you have UTC time? Are you thinking of the case where the desired behavior is to preserve the local time, rather than the absolute time?
Not exactly boned but it probably doesn’t make practical difference to store “local time + tzinfo timezone” than just UTC time.
- You record an event occurring at local time
- You store it as UTC
- Local time zone definition changes
- Well whoop de loo, now you need to go through tzinfo to make sense of the past data anyway rather than relying on a known offset
Even if you store everything in UTC, you may be safe… but figuring out the local time is still convoluted and involves a trip through tzinfo.
I think the comment is specifically talking about storing future times, and contemplating future changes to the local time zone offsets.
If I say that something is going to happen at noon local time on July 1, 2030 in New York, we know that is, under current rules, going to happen at 16:00 UTC. But what if the US changes its daylight savings rules between now and 2030? The canonical time for that event is noon local time, and the offset between local time and UTC can only certainly be determined with past events, so future events defined by local will necessarily have some uncertainty when it comes to UTC.
So many things would be fucked by a TZ change that it very rarely makes sense to consider it.
You’re making a calendar app? Fuck it…some folks are gonna get confused…solved by simply emailing your users and telling them to reschedule shit because there’s kind of a big event going on that everyone knows about and has been planning for for years. Hell in all liklihood this is probably easily solved by simply doing a mass migration of events scheduled before the TZ change.
You’re coding for nuclear weapons? Maybe consider it. But probably not.
That is to say: there are ways to solve problems without resorting to writing the most complicated bullshit code ever seen. Unless of course you work on my team - in which case you’d be right at home.
If you use utc here and a time zone definition changes, you’re boned
I’m pretty sure that things like the tz database exist exactly for such a case.
The TZ database doesn’t tell us what the offsets will be in the future. Only the past.
“boned”
nice word choice
It should be implemented in people’s brains.
How this goes, usually, is:
Them:…before 6PM.
Me: 6PM… Ours? The server’s? The user’s?
Them: GMT, of course.
Me: So that’s 7PM London right now, and changes to 6PM in November?
Them: What no are you stupid. Always 6PM GMT.
Me:* jumps off a cliff*
Reminds me of a LARP I was on one time. A group of people I was doing stuff with ended up always meeting at 10 because we redefined “10” to mean “whenever we all meet”.
Don’t get it. Is this implying GMT has daylight savings?
GMT doesn’t have daylight savings, but most people won’t be as precise in language. Here in Germany, we might also tell people “GMT+2”, even though it changes to GMT+1 in winter. Like, I don’t even know what the correct shorthand would be for our timezone…
CET?
That is why lots of time zone selectors allow you to select “Europe/Berlin”: then it is clear that depending on the time of year this is UTC+1 or UTC+2.
I use TZ identifiers, and confirm the expected behaviour (“Berlin time, correct?”), as then I know how I should handle DST changes.
GMT doesn’t have daylight savings but London does
Unix timestamp or death.
Well if it’s a 32bit timestamp you’re screwed after 19 January 2038 (at 03:14:07 UTC)
I don’t think modern systems use 32bit stamps anymore, the ones that do are built to fail
Maybe they’re planning on dying before then? In which case they’re fine.
Yeah… the “-7:00” offset is not enough information for most uses.
It’s barely enough to use as timestamps in email headers.
