Falsehoods programmers believe about time zones (2020)

https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/

by bookofjoe • 2 years ago

95 84 2 years ago

relbeek2• 2 years ago

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.

theamk• 2 years ago

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.

pie_flavor• 2 years ago

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.

ethanbond• 2 years ago

The US is in six time zones (with territories in more).

Anarch157a• 2 years ago

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.

Hamuko• 2 years ago

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.

PaulDavisThe1st4• 2 years ago

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.

creatonez• 2 years ago

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.

hbn2• 2 years ago

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.

nitwit005• 2 years ago

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.

acheron• 2 years ago

"falsehoods programmers believe" articles considered harmful.

sdflhasjd• 2 years ago

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

cqqxo4zV46cp• 2 years ago

For fun and profit!

SOLAR_FIELDS• 2 years ago

Falsehoods programmers believe about “falsehoods programmers believe” articles

happytoexplain• 2 years ago

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.

playingalong• 2 years ago

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.

ChrisMarshallNY• 2 years ago

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

curiousgal• 2 years ago

I honestly did not know a lot of things listed.

BWStearns• 2 years ago

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.

lxgr2• 2 years ago

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

nzach• 2 years ago

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.

sophacles• 2 years ago

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).

greenyoda• 2 years ago

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

AndrewStephens• 2 years ago

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"?

orenlindsey• 2 years ago

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.

eesmith• 2 years ago

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

chankstein38• 2 years ago

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.

kps• 2 years ago

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.

deathanatos2• 2 years 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".

perrygeo2• 2 years 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• 2 years ago

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.

perrygeo2• 2 years ago

https://www.972mag.com/the-worlds-only-ethnic-time-zone/

theoriginaldave3• 2 years ago

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.

nerdbert• 2 years ago

But don't you have 01.00 - 02.00 EST and then 01.00 - 02.00 EDT?

deathanatos2• 2 years 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.

foobarchu2• 2 years 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• 2 years ago

Your issue with the GPS coordinates sounds more like a noise/signal processing problem than anything.

lxgr2• 2 years ago

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).

madcaptenor3• 2 years ago

Do Americans even know country calling codes exist?

bxparks• 2 years ago

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.

beardyw• 2 years ago

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

bibliotekka• 2 years ago

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=...)

bee_rider• 2 years ago

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.

PaulDavisThe1st4• 2 years ago

When you collect a time/date entry from a user, what are your instructions to them?

LK5ZJwMwgBbHuVI5• 2 years ago

<input type="datetime-local"> (plus some JS to turn it into a timestamp in UTC, since HTML is stupid)

CWuestefeld2• 2 years ago

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.

candiddevmike• 2 years ago

Unless it's MST and they live in Arizona

manchmalscott2• 2 years ago

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.

shagie• 2 years ago

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

  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)

Btw, the fun job for scheduling would be at Lake Powell and the Glenn Canyon Dam where you could have people who live in Utah, Arizona, Navajo nation, and Hopi Nation.

https://www.timeanddate.com/time/us/arizona-no-dst.html

macintux• 2 years ago

Every summer I take up this battle again. Don Quixote had a better shot with his windmills.

maxwell2• 2 years ago

Same, I used to dutifully shift my office hours between EST and EDT accordingly in my email signature.

madcaptenor3• 2 years ago

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.

bobbylarrybobby• 2 years ago

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”.)

LK5ZJwMwgBbHuVI5• 2 years ago

That's absolutely what standard time means. As opposed to local mean time. YOU are creating confusion.

aksss• 2 years ago

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.

zX41ZdbW• 2 years ago

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.

madcaptenor3• 2 years ago

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).

aorloff2• 2 years ago

Everything happens in epochtime. How you want that displayed is up to you.

dbrueck2• 2 years ago

Unfortunately, this take is overly simplistic for a lot of scenarios (I'm looking at you, broadcast TV).

PaulDavisThe1st4• 2 years ago

But what about things that have already happened? Negative epochtime?

aorloff2• 2 years ago

Things that happened before 1970 ?

dbrueck2• 2 years 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.

chmike• 2 years ago

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.

rswail• 2 years ago

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.

dang• 2 years ago

Discussed at the time:

Falsehoods programmers believe about time zones - https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16 comments)

hbn2• 2 years ago

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.

LK5ZJwMwgBbHuVI5• 2 years ago

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?

WirelessGigabit• 2 years ago

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.

pentaphobe• 2 years ago

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

Falsehoods programmers believe about time zones (2020)

Related Stories