3 ms·
> There is a standard format for declaring time zones The IANA tzdb is as standard of a format as you're going to get. It is even managed by IANA these days, s
by deathanatos 3y ago
> There is a standard format for declaring time zones
The IANA tzdb is as standard of a format as you're going to get. It is even managed by IANA these days, so I'm not sure what more you could want.
But yes, it's just a DB. That's all it can ever hope to be, given these are decided by local regulations/politics.
> GPS coordinates
GPS fix+UTC time isn't sufficient to determine time zone. I know … because I've tried! A GPS fix is always ± some error, so you can imagine it as a circle — not a point — and the user is in that circle, somewhere. Now, place that circle on the boundary between zones: which zone is the circle in?
In practice, this resulted in users in a system I worked on flip/flopping between the two zones, rapidly enough that they accumulated enough rows in the database that eventually, a query for the user's time zones caused an outage because we also didn't have an index on that table.
> A country stays in the same time zone during Daylight Saving Time
> Texas goes from Central Standard Time to Central Daylight Time.
This is the wrong way to model zones in your head. Barring legislation changing it, Texas is in America/Chicago (mostly), year-round. They're still in America/Chicago, regardless of whether they're in DST or not. The zone is the same, but the offset — and the local colloquialism used to denote the time (e.g., "CST" or "CDT") might change.
> Every time zone has it's (sic) own name
> Which country should get to claim "Eastern Standard Time"?
That's why it's called America/New_York. That normal people don't know the name of their timezones is … a UI challenge, I admit. But that's why you see dialogs like the one that the OP criticizes. I've even run across adults — working in an airport — that don't even know the local name (like "Eastern" or "Central") of the zone.
> There is always an unambiguous conversion from one time zone to another
… there is … but the article author uses a strawman here. Yeah, if you don't know the input timestamp, then you're going to have a hell of a time converting it. Yes, you need to know which zone, and the DST flag's value. But that's just "I know what time I want to convert".
- perrygeo 3y ago> GPS fix+UTC time isn't sufficient to determine time zone Most people understand that position alone can't determine time zones because their definitions change constantly. But surely with time + better positional accuracy we could do it? Nope. Even with infinite precision in four dimensions, it's still a logical fallacy. Why? Because timezones are political definitions and many regions of the earth are contested (i.e. political control is ambiguous). So it is fundamentally impossible to determine time zone without identifying the political affiliation of the observer.
- awhitty 3y agoI came here curious if anyone would point this out. I was surprised to see the post describing UTC + lat/lng as a common practice in APIs without discussing this quirk. E.g. to your point, China's border with Bhutan is politically "fuzzy". Bhutan uses UTC+6, and Beijing Time is UTC+8. Weird that the post acknowledges timezones are a political construct but misses the fact that borders are too.
- perrygeo 3y agohttps://www.972mag.com/the-worlds-only-ethnic-time-zone/ https://www.972mag.com/the-worlds-only-ethnic-time-zone/
- theoriginaldave 3y agoThere is not always an unambiguous conversion from one TZ to another. DST will always give you an ambiguous localized time. If you take input in local time, and it's in the repeating DST window (01:00<=t<02:00 for spring in USA). Don't get me started on start of day or start of week in multi-TZ /culture environments. If you think times are bad, look at calendars.
- nerdbert 3y agoBut don't you have 01.00 - 02.00 EST and then 01.00 - 02.00 EDT?
- theoriginaldave 3y agoYes, but for user input for times they normally don't include offset. So if I have a regularly scheduled event at 01:30 on February 29 should it happen at 30 min before 2:00am (2:00am only happens once or 31 min after the first 12:59 am. I can choose one or the other (or both)
- deathanatos 3y ago> DST will always give you an ambiguous localized time. If you take input in local time, and it's in the repeating DST window (01:00<=t<02:00 for spring in USA). No, it won't, and I was explicit about this in the comment you're replying to: the DST flag is part of your input time. If you don't know the DST flag's value, you don't have a timestamp.
- foobarchu 3y ago> But that's why you see dialogs like the one that the OP criticizes. Nitpicking, I dont think they were criticizing the Ubuntu approach at all, just using it to demonstrate one of the many common ways of timezone-picking.
- epgui 3y agoYour issue with the GPS coordinates sounds more like a noise/signal processing problem than anything.