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.
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.
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.
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.
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.
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"!
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.