Falsehoods programmers believe about time zones (2020)
zainrizvi.io
zainrizvi.io
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".
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.
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.
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.
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.
Never fond of these articles myself either. One I read was "Falsehoods programmers believe about names" and part of the reason they annoy me the assumption that programmers create these requirements in the first place. Like... I believe that all users are simply identified by a GUID, it's someone else that wanted your first name, family name, pet name or whatever.
This one seems particularly weak though, the biggest timezone mistakes are usually made by users. We had a recent one where all the scheduling got fugged up because someone was changing the timezones to account for daylight savings. One of those things where I can laugh with my fellow programmers... "users, am i right XD", while secretly wondering how to improve the timezone selector UI.
However, I think these lists are using the word "believe" to mean "incidentally assume in implementation". It doesn't require a conscious belief to write code that makes these assumptions.
TZ are a fun project. I found that it's difficult to translate a long/lat into a TZ ID, so I wrote this[0].
Works a charm. It's based on the Timezone Boundary Builder[1].
[EDIT] Looks like I'll have to revisit the tests. The latest boundary map is much smaller, and triggers a bunch of errors. Most of my tests are just around boundaries. In the meantime, use the 2023b release.
It's good to have assumptions called out now and then so next time we have to handle the space we can remember to decide which edge cases are relevant.
And since there's always new programmers entering the market, there's a never-ending supply of people who these articles might just save a lot of headache, myself included at some point.
"Problem x is very hard, don't make solving it part of your plan" is some of the best advice you can get. It can be fun to still try, but maybe not in production or on a timeline.
Even then I really don't mind that much, especially when you consider how many articles exists that argue the only correct way to handle multiple timezones is to always convert to UTC before saving.
Heck - I live in a house that has an address like this:
123 1/2 Some St
There are at least another dozen 1/2 addresses in my neighborhood alone. Yet for some reason about half the websites I try to order from refuse to accept it as a valid address. My driver's license is cool with that address, but several state government websites even refuse to accept it as an address.
This isn't even a weird example like Nepal time.
As another commentor said - people probably wouldn't state "i believe no addresses include fractional lot numbers" but they would likely state: "I believe anyone in the US can order from my site" - which is basically the same thing (pedantic quibbling aside).
There's a similar "falsehoods" list devoted to addresses, which mentions fractional numbers:
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
Apparently, there are even street names that contain fractions, such as "43rd ½ St". Imagine the problems of living at "123 ½ 43rd ½ St"!
Half of the year, without fail, it converts to MDT.
12:30 PM Tuesday, Eastern Time (ET) is 10:30 AM Tuesday, in Phoenix, AZ
Unless they live within the Hopi Nation which is an enclave within the Navajo Nation which does not follow daylight savings time.
Going north from Winslow, AZ to the Glenn Canyon Dam you will
Be in non-DST (Winslow, Arizona)
Be in DST (Navajo)
Be in non-DST (Hopi)
Be in DST (Navajo)
Be in non-DST (Hopi)
Be in DST (Tuba City, Navajo)
Be in non-DST (Page, AZ)
#3 ("more countries than timezones") author should have known that, given that he is in the US which has 4 timezone.
#7 and #11 describe author's timezone
this list seems pretty made up.
Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments)
> A similar issue exists for Casey Antarctic station in the year 2010. They changed the time three hours back on 5 Mar, 02:00.
Something similar happens at the Norwegian base Troll, which is +0 in southern summer (in accordance with its location) and +2 in southern winter (which is northern summer, so they match the time in Norway).
I doubt any Pacific Islanders decided this - probably more to do with the USA's illegal annexation of Hawai'i
https://en.m.wikipedia.org/wiki/Overthrow_of_the_Hawaiian_Ki...
https://stackoverflow.com/questions/2234121/can-2-timezone-b... has "There has been recent discussion on the TZ mailing list about the area of China known as Xinjiang, which has a mixed population of Han Chinese and of Uyghurs. It seems that the Han use the standard Chinese time zone (Asia/Beijing), but the Uyghurs often use a local time zone. This is now encapsulated in the Olson database, with the name Asia/Urumqi for the Uyghur time zone."
When I had T-Mobile Home Internet, my IP address would geolocate me to random parts of the country regularly. It was rare that it landed in my time zone let alone my state. It got really confusing for store websites because they'd try to locate me based on IP and serve me stores in Wisconsin while I live on the east coast.
1. Time and Date programming; and,
2. Debugging.
#1 leads naturally to #2.
Thankfully most programmers don't really have to worry about all of these edge cases unless they are writing their own timezone libraries.
In which he claims that DST must be a distinct timezone from standard time, followed shortly by
> Misconception #15: There is always an unambiguous conversion from one time zone to another
Which is absolutely true, if you treat DST as a distinct timezone.
Anyway... if you didn't already know 90% of these before starting, there are plenty of services that already do this very thing.
Oh, and how is punching a date and a timezone into Google Calendar too technical for her?
...except for the fact that the city of Lloydminster is located in both Saskatchewan and Alberta, and follows daylight savings with the rest of Alberta. And the small towns surrounding Lloydminster don't want to be in a different timezone from the big nearby city, so they also follow daylight savings.
So Saskatchewan is only in 1 timezone during the summer months.
Oh, and does it matter? You could just as well store the number of days and have more than enough precision with regard to events which happened half a century ago.
And back to Arizona. We know Arizona doesn't practice Daylight Savings, but the Navajo Nation, part of AZ does. But inside of Navajo Nation there is the Hopi Reservation which does not practice Daylight Savings.