Falsehoods programmers believe about time zones (2020)(zainrizvi.io)
zainrizvi.io
Falsehoods programmers believe about time zones (2020)
https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/
86 comments
There 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.
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.
> 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.
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.
But don't you have 01.00 - 02.00 EST and then 01.00 - 02.00 EDT?
Yes, 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)
> 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.
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.
Your issue with the GPS coordinates sounds more like a noise/signal processing problem than anything.
> 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.
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.
I 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.
Please stop writing these things. The initial name one was valid, but all these follow ups end up being a list of things hardly anyone believes, and mostly come across as insulting.
I absolutely guarantee that most programmers I work with "believe" most of these things.
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.
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.
Actually it's a good test for seniority in programming. In school they hardly ever teach these factoids. Yet in practical everyday programming you eventually run into some of these issues. Even if you are not a maintainer of a tz library.
They don't really bother me. They aren't AI spam, and some folks may enjoy them. It's pretty easy to not click on a link, for me.
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.
[0] https://github.com/LittleGreenViper/LGV_TZ_Lookup
[1] https://github.com/evansiroky/timezone-boundary-builder
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.
[0] https://github.com/LittleGreenViper/LGV_TZ_Lookup
[1] https://github.com/evansiroky/timezone-boundary-builder
"Falsehoods" articles will continue until the average truthfulness of programmer beliefs increases.
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.
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.
You can scoff but I have maintained and fixed code that assumed more than one of these falsehoods. I think it is a pretty fair title, would you prefer "Common assumptions about timezones that turn out to be wrong"?
No one thinks developers literally believe this, but if your only information came from interacting with the code we produce then you would likely arrive at this conclusion.
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.
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.
"falsehoods programmers believe" articles considered harmful.
Falsehoods programmers believe about “falsehoods programmers believe” articles
"Falsehoods blog writers believe about programmers."
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.
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.
For fun and profit!
And yet I've encountered software that fails to account for most of the items on most of the lists.
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).
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).
> 123 1/2 Some St
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"!
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"!
I think this title was a little too clickbaity for this article as they don't show anything too surprising about timezones.
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.
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.
I honestly did not know a lot of things listed.
A pet peeve of mine: "standard time" as in "Eastern Standard Time" does not mean "use the time zone that is the norm that people on the east coast use". It actually means the opposite of daylight savings time. So when someone says, in the middle of July, "call me at 1pm EST", they're creating confusion.
Every summer I take up this battle again. Don Quixote had a better shot with his windmills.
Same, I used to dutifully shift my office hours between EST and EDT accordingly in my email signature.
I just use "ET", works all year.
Can't one just write ET instead?
Only when posting their home phone number
US ET
Unless it's MST and they live in Arizona
Google is the worst for this. I'll type something along the lines of "12:30 PM eastern to MST". I specify MST. I specify standard time, i.e not daylight savings. I live in Arizona, Google knows I live in Arizona, from my IP address and from my account that I'm logged into.
Half of the year, without fail, it converts to MDT.
Half of the year, without fail, it converts to MDT.
Outlook also sends your time zone as MST if you live in AZ (which is technically correct), but it’s super annoying as half the year you have to remind people that those times are really Pacific Time
> 12:30 PM eastern to arizona
12:30 PM Tuesday, Eastern Time (ET) is 10:30 AM Tuesday, in Phoenix, AZ
12:30 PM Tuesday, Eastern Time (ET) is 10:30 AM Tuesday, in Phoenix, AZ
What happens if you try "my time" or "local time"?
I guess we’ll find out in March, that’s a good question.
Another option is to give it a large city to orient with. If you said "in Phoenix" it would probably figure it out via IANA timezones or something similar
Unless they live within the Navajo Nation inside of Arizona, then it follows daylight savings time.
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
https://www.timeanddate.com/time/us/arizona-no-dst.html
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)
https://www.timeanddate.com/time/us/arizona-no-dst.html
Yep, local businesses near Page have to explain this to pretty much every tourist who books anything with a specific time in the general area. Huge waste of time.
They're only creating confusion if you're being deliberately obtuse. Which I'm tempted to be when people call a meeting I don't want to go to and daylight savings time is in effect.
The issue is that computers are deliberately obtuse, so if you copy and paste a time that someone sends you, including the EST time zone, into a time zone converter, you may get a result that's off by an hour. (This is why I always just say “US ET”.)
That's absolutely what standard time means. As opposed to local mean time. YOU are creating confusion.
Are there really people who believe those things? Author's profile says Houston, TX which means they should know all about multiple timezones and DST at least.
#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.
#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.
In fact this list seems much like the original: take any programmer and challenge him to come up with counterexamples and it'll likely be a breeze, but give him a task anywhere adjacent to the concept and the falsehoods will be very easily assumed and encoded into the result.
It's not literally about beliefs, but about the logical chain of nuanced considerations you must go through to implement time. You only "believe" them in the sense that when your hands hit your keyboard to write the first draft of code, you will likely write code that assumes multiple of these misconceptions are true. Hairy problems always seem simpler on first glance than they actually are.
The US is in six time zones (with territories in more).
On the other hand, UTC-3 has 8 countries in it, which more than offsets that. Even EST (UTC-5) has a whole bunch of countries in it, including Cuba, Jamaica, Brazil, et. al.
Yeah, a lot of these seem pretty obvious after doing even some amount of work with timezones. Or in the case of #7, it's pretty obvious to anyone who a) lives in a country with DST (which covers a large swath of North America and Europe) b) knows what UTC is.
Countries in North America are very big though, and time zones can be shared between multiple countries (e.g. US and Canada). Just because we span a lot of timezones here, I wouldn't be confident to say, especially thanks to the eastern hemisphere, there isn't more countries than time zones. A timezone is a big, vertical slice that hits a lot of countries, I would have just as well believed there was enough overlap to have more countries than time zones.
Given that a single time zone covers, what, maybe 9 countries in Europe, your point about #countries vs #tz is not really that obvious at all.
Discussed at the time:
Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments)
Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments)
Localization past Unix time stamp should be handled by the OS anyway. If I somehow got myself caring about any of this, I’d be very worried that I was doing something wrong.
When you collect a time/date entry from a user, what are your instructions to them?
<input type="datetime-local"> (plus some JS to turn it into a timestamp in UTC, since HTML is stupid)
Also fun reading: "Limitations on time zones support" at https://clickhouse.com/docs/en/sql-reference/data-types/date...
> A similar issue exists for Casey Antarctic station in the year 2010. They changed the time three hours back on 5 Mar, 02:00.
> A similar issue exists for Casey Antarctic station in the year 2010. They changed the time three hours back on 5 Mar, 02:00.
It looks like Casey is +11 in southern summer and +8 in southern winter - apparently they're supplied out of Tasmania, so they match Tasmanian time in the summer, but match the time of their longitude during the winter.
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).
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).
Interesting fact. If you travel between Britain and India and you have a wristwatch with hands, you can turn it upside down and get roughly the right time
That is kinda interesting. Seems to work better in the winter (https://www.timeanddate.com/worldclock/meetingtime.html?iso=...) than summer (https://www.timeanddate.com/worldclock/meetingtime.html?iso=...)
Closely related to "mapping UTC offsets to timezones": Mapping country calling codes to countries. Please just don't (if you're not going to handle NANP correctly).
Do Americans even know country calling codes exist?
In their defense, making the long distance prefix (1) the same as the country prefix (1) did not help spread that knowledge. I think most American know that something called "country calling code" exists, but probably couldn't tell you the code for the US. And I'd guess that most probably don't know that the +1 code includes Canada and most of the Caribbean islands.
> Why that crazy range? That was a result of pacific islanders decided they wanted to be on a specific side of the international date line.
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...
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...
A possible solution could be to geolocate the user's IP address (I know, they could use a VPN or something but for 99% of users it would work) or simply ask for location permissions and then have a database of time offsets mapped into geographical space. But you would still have an unwieldy database of polygons that has to be updated every time a country changes their time.
Falsehood #32: "If you have a UTC timestamp and the GPS coordinates, you can always determine the local time: Palestine and Israel have different time zones. So in the West Bank, the time zone depends on if you're Palestinian or an Israeli settler. If you don't know which person you're computing the time zone for, the local time is ambiguous (via haxney),"
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."
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."
> 99% of users it would work
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.
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.
Yes, I routinely get located in a different province; there are approximately zero consequences to a geolocation provider for getting it wrong. Worst are the sites that I grant my actual location and then use some IP-based fantasy anyway.
It would have been better to write this as “rules for working with time zones”, rather than inverting everything and calling them misconceptions. The approach taken is confusing to read and, like others have pointed out, I don’t believe for a second that very many people hold these affirmative misconceptions about time zones.
For years I've said that programmers need only two courses to learn how to program:
1. Time and Date programming; and,
2. Debugging.
#1 leads naturally to #2.
1. Time and Date programming; and,
2. Debugging.
#1 leads naturally to #2.
Most of these I already knew except the -12 to +14 UTC.
Thankfully most programmers don't really have to worry about all of these edge cases unless they are writing their own timezone libraries.
Thankfully most programmers don't really have to worry about all of these edge cases unless they are writing their own timezone libraries.
What I don't understand is why computers and operating systems have not adopted the TAI as time reference which is monotonic, etc. Time is a complete mess.
> Misconception #11: A country stays in the same time zone during Daylight Saving Time
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?
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?
We have a similar situation to Arizona here in Saskatchewan. The province has its own time zone (Saskatchewan Time) that never changes along with the rest of Canada.
...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.
...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.
Everything happens in epochtime. How you want that displayed is up to you.
Unfortunately, this take is overly simplistic for a lot of scenarios (I'm looking at you, broadcast TV).
But what about things that have already happened? Negative epochtime?
Things that happened before 1970 ?
Sure. When I want to reference a time before 1970 in a computer, how do I use epochtime? Just negative values?
Yes. That's why time_t is signed, after all. Do you need to represent times before 1901? Then use 64 bits!
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.
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.
Infuriating fact if you have to deal with historical time stuff: in the U.S., it used to be that not only could each city decide whether or not it observed DST, it could also decide on its own when DST began and ended. It was this way until 1966, at which point a law was passed to make it uniform, and the duty to enforce it fell on the Department of Transportation.
Here's another one. The S in a time zone's name can stand for Standard or Summer.
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.
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.
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".