this post was submitted on 29 Jun 2024
886 points (94.7% liked)
Programmer Humor
32710 readers
1209 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 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.