this post was submitted on 29 Jun 2024
861 points (94.8% liked)
Programmer Humor
31224 readers
64 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The creator of DST gets the first slap. Then the timezones asshole.
I'm planning to do a presentation at work on how to deal with dates/times/timezones/conversion/etc in the next few weeks some time. I figure it would be a good topic to cover. I'm going to start my talk by saying "first, imagine there is no such thing as timezones or DST." And then build on that.
Sandford Fleming (the guy who invented time zones) actually made it easier.
Before timezones, every town had their own clock that defined the time for their town and was loosely set such that “noon is when the sun is at its highest point in the sky.” Which couldn’t be measured all that accurately.
If it wasn’t for Fleming, we’d be dealing with every city or town having a separate time zone.
Save a slap for the dude who invented sundials, and another slap for the dude who invented civilization.
Some asshole had the idea to water a seed and now I have to pay taxes. Fuck that guy.
Is he cute?
Not any more. But some of the IRS guys are smokin' hot, I'm sure, if that's what you're into.
This but unironically.
Save a slap for the dude who invented slaps!
Everyone complaining about timezones is truly missing the forests for the trees.
Timezones aren't a problem. Stupid fucking daylight savings is though.
Yes, I agree. Even if we could magically make all computers work with it, shouldn't it logically be the other way? Wouldn't a later sunset in winter be better lol? But yeah, it's dumb either way. If we want to have different hours then shouldn't we adjust our daily routines instead of adjusting our clocks??
I really don't care if it gets dark at 3:30 or 4:40 in the winter. Either way, there is no doing things in sunshine after work. Fortunately, I can use part of the day time for personal things and work later when I get back home.
Imagine, if we were just all on the same time. It'd just make things, a little easier.
All in the same time? But... Then the sun might go down at noon. That doesn't make sense...
Wait... Noon? Noooon...
Oh now that's worse
We must establish a new order of monks, who all get up at 6am UTC. We can call them in sync
Just let go of all meaning. 2 PM can be in the middle of the night if you just let go.
It just means the monks have to get up at 3am.
Life, that is. It would just make life a little easier.
Save a slap for the leap seconds creator.
What's DST?
Edit: oh it means Daylights Savings Time
Dick sucking time
That's the only time zone I'm for!
You might want to show them this video https://youtu.be/-5wpm-gesOY
Here's what I would include. I always seem to end up with systems that try really, really hard to send a datetime without a timezone. You should explain to them why its ambiguous. Pick a time between 1am and 2am on the day that DST shifts to standard time. This date has two distinct times that display as 1:15am in local time. We need to know if it was US/Central Daylight time or US/Central Standard Time in order to convert "Nov 3, 2024 1:15:00" to universal time.
Yes, for sure.
Unfortunately, many moons ago before I started working where I currently work, the decision was made that they'd standardize, roughly speaking, on the timezone of the corporate headquarters. (I work in the same timezone as corporate, so that's my timezone. So it's not as bad for me as for folks who work in far-flung locations. But it's still a huge PITA even for me.)
And when I say "roughly speaking", I mean that there's plenty of data we keep in the timezone of the location it pertains to. Like store open/close times are stored in a corporate database in the store's timezone. Which... I guess honestly that makes some sense. (Well, it doesn't make any sense because DST is bullshit, but given that we have to deal with DST, I guess it makes sense to store location open/close times in the store's timezone because they want their open/close times to shift with DST. If we stored those open/close times in UTC, we'd have to do some painful adjustments to account for DST in locations that observe it.)
Oh! And we have RESTful services owned by other teams that when you refer to a location by number and it returns information about the location, it uses the three-letter identifier to indicate what timezone they're in rather than the cities (like "America/Phoenix", or "America/Puerto_Rico", or "America/Denver" or whatever), so we have to have special logic in our applications to be like "if they're in MNT and they're in Arizona then... but if they're in MNT and not in Arizona then..."
Damn. Now I'm ranting. Lol.
So what I hear is that you are storing dateTime values with a timezone and are storing a timezone. They shouldn't be returning MNT for Arizona because they aren't in Mountain time. You could put them in Mountain Standard Time because that is effective what AZ is -- mountain time with no timezone. Of course this isn't the full story because sovereign nations aren't beholden to AZ legislature and they can (and do) run in different time zones (Mountain time with DST).
Hmm?
Google's telling me Arizona is in mountain time. For all locations in mountain time, the service in question returns "MST" (and doesn't adjust to "MDT" for part of the year or anything.)
But Arizona doesn't observe daylight saving's time like the rest of those in mountain time.
Now, if the service in question returned "America/Phoenix" for Arizona locations and "America/Denver" (I think that's right) for mountain time locations outside of Arizona, our code would be as simple as
whateverMethodInTheStandardLibraryConvertsToTimezone(dateTime, timezone). But as it is, we have to do something likewhateverMethodInTheStandardLibraryConvertsToTimezone(dateTime, state == "AZ" ? "America/Phoenix" : {"MST":"America/Denver","CST":"America/Chicago",...}[timezone]).Also, I should mention we only have to deal with U.S. states plus Puerto Rico where I work. No UTC+8:45 timezones come into play or anything, at least. Also no locations in, say, the Navajo nation in Arizona currently.
I missed a few words so the first sentence was especially hard to understand.
Honestly, I'd just add a column to your locations table to store the time zone and don't use google's service. If you have a store in Gilbert, AZ, set this column to America/Phoenix. Minneapolis would get America/Chicago etc.
Ha! I think you're still misunderstanding me. (Maybe misunderstanding me more than you were previously.)
We're not using any Google service in relation to the timezones things in question. You said in your post "They shouldn’t be returning MNT for Arizona because they aren’t in Mountain time." The only reason I mentioned Google is because after reading that sentence, I googled to see what timezone Arizona is in (because I thought I remembered it was in mountain time) and my Google search seems to confirm that Arizona is indeed in the mountain time zone.
Exactly what I'm getting at. They should be using the "America/Phoenix" format for identifying timezones, not "MST". But they use the latter and I don't have any control over the service in question because it's owned by another team. We could nag them, but they don't really have a lot of incentive to make such a fix, so realistically that task would probably die at the bottom of their backlog. My team only consumes data from the service in question. And because it's doing things in that way, my team has to have extra complexity in our code to account for it.
The talk I'm planning to give to my team isn't going to be related to any of that. My team also runs into timezone weirdness, of course, because so does every developer, and a better understanding about such things is definitely going to benefit everyone. That story about the other team using the three-letter abbreviations in stead of, say "America/Phoenix" was just me ranting about how things are done by other teams at the company where I work.
You should be bugging them every day to fix their data. Even if you have to call a new api that returns Olsen timezone names. That way you don't break code that depends on existing internal timezone names.
Oh yeah, please do imagine there is no such thing as a time zone.
On an ellipsoid!
No, see, how it would work without timezones is:
Note that the Sun position is not consistent throught the year and varies widely based on your latitude.
In Iceland (and also Alaska) you can have the Sun for a full 24 hours in the sky (they call it "midnight sun") during Summer solstice (with extremelly short nights the whole summer) and the opposite happens in Winter, with long periods of night time.
Just the days of the week? you mean that 2024-06-30 23:59 and 2024-07-01 00:01 can both be the same weekday and at the same time be different days? Would the definition of "day" be different based on whether you are talking about "day of the week" vs "universal day"?
Good call. The definitions of "noon" and "midnight" would need to be formalized a bit more, but given any line of longitude, the sun passes directly over that line of longitude "exactly" once every 24 hours. (I put "exactly" in quotes because even that isn't quite exactly true, but we account for that kind of thing with leap seconds.) So you could base noon on something like "when the sun is directly over a point on such longitudinal line (and then round to the nearest hour)."
Could still be a little weird near the poles, but I think that definition would still be sensical. If you're way up north, for instance, and you're in the summer period when the sun never sets, you still just figure out your longitude and figure when the sun passes directly over some point on that longitudinal line.
Though in practice, I'd suspect the area right around the poles would pretty much just need to just decide on something and go with it so they don't end up having to do calculations to figure out whether it's "afternoon" or "morning" every time they move a few feet. Heh. (Not that a lot of folks spend a lot of time that close to the poles.) Maybe they'd just decide arbitrarily that the current day of the week and period of the day are whatever they currently are in Greenwich. Or maybe even abandon the use og day of the week and period of the day all together.
Yup.
I'm just thinking about things like scheduling dentist appointments at my local dentist. I'd think it would be less confusing for ordinary local interactions like that if we could say "next Wednesday at 20:00" rather than having to keep track of the fact that depending what period of the day it is (relative to landmarks like "dinner time" or "midmorning") it may be a different day of the week.
And it's not like there aren't awkward mismatches beteen days of the week and days of the month now. Months don't always start on the first day of the week, for instance. (Hell. We don't even agree on what the first day of the week is.) "Weeks" are an artifact of lunar calendars. (And, to be fair, so are months.)
(And while we're on the topic of months, we should have 13 of 'em. 12 of length 30 each and one at the end of 5 days or on leap years 6 days. And they should be called "first month", "second month", "third month", etc. None of this "for weird historical reasons, October is the 10th month, even though the prefix 'oct' would seem to indicate it should be the 8th" bs. Lol.)
regarding day change, you could also just have it change at UTC midnight and the entire planet bongs at that time if they're awake.
Yeah. I figured the day-of-the-month change should definitely happen at UTC midnight. I kindof like the idea that a day of the week lasts from before I wake up to after I go to sleep. (Or at least that there's no changeover during business hours.)
But hell. If you wanted to run for president of the world on a platform of reforming date/time tracking but planned for the days of the week to change at midnight UTC, I'd still vote for you.
Bank holidays would be really awkward. You start wort at 23 and the next day is off so you would just have to work that one hour.
Office workers could probably move hours around. It would get complicated for shift workers though. Paying overtime for work on holidays?
What would happen is that unofficially they determine a logical working day to be between 12:00 and 00:00 in US/Central since that maps to 6am to 6pm. In essence, we'd still have timezones but they would not have formal definitions.
My experience is that you start work and the next day is off so you just lock the doors and keep working, but maybe there are financial institutions without backlogs idunno.
How is this any different for other days of the month. In US/Central (6 hours behind UTC), we would always switch over to the next day at 18:00.
If I'm understanding what you're getting at, I think you're misunderstanding. I wasn't saying the day of the month change would happen at different times of day for different days of the month. I was saying the day of the month change would happen at different times of day for different longitudes. (I said "for different people", though "for different longitudes" or "for different locations" would have been a better way to say that.)
I believe you are correct. I read your statement as meaning when the month changes.
But your explanation also seems backwards. Currently, every timezone changes to the next day at their time. US/Eastern switches days at 4:00am utc (assuming DST) and US/Central follows an hour later. With no timezones, everyone would switch days at the time time 00:00 UTC. It just may be 5/6 hours early than we're used to in US/Central time zone for example.
Well, I do think it's useful to be able to speak in terms of "the period of time from the middle of the dark period of the day to the following middle of the dark period" for conversations with other locals. And that's what I was talking about with regard to the days of the week changing over at "midnight" (that is, the middle of the dark period).
So, if I lived somewhere where the sun rose at 14:00 UTC every "day", I would have to keep track of the fact that the date would change to the next date (from the 19th to the 20th, for instance) every mid-to-late "afternoon". A small price to pay, in my estimation, but still a price to pay.
So, I dunno. Doesn't feel backwards to me. Folks are still probably going to think in terms of their "day". Like from when they get up to when they go to bed. Not in terms of when Greenwich gets up and goes to bed. So I do think it's worth considering things from the perspective of people who just want to make sure they get to work on time so they don't get laid off. And from that perspective, it makes more sense to say "the date changes over one hour before I get off of work" (which is "mid to late afternoon" even though it's UTC 0:00).
You're replacing codified standards for local time with ad hoc conventions like they had before time zones.
DST people should get hung. By three balls. Fuck them.
Is this something that is going to be publicly available? If so, post a link when you have it.