[HN Gopher] Falsehoods programmers believe about time zones (2020)
___________________________________________________________________
Falsehoods programmers believe about time zones (2020)
Author : bookofjoe
Score : 83 points
Date : 2024-02-13 17:35 UTC (5 hours ago)
(HTM) web link (www.zainrizvi.io)
(TXT) w3m dump (www.zainrizvi.io)
| theamk wrote:
| 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 wrote:
| 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 wrote:
| The US is in _six_ time zones (with territories in more).
| Anarch157a wrote:
| 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 wrote:
| 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.
| PaulDavisThe1st wrote:
| 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 wrote:
| 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.
| hbn wrote:
| 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 wrote:
| 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 wrote:
| "falsehoods programmers believe" articles considered harmful.
| sdflhasjd wrote:
| "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 wrote:
| For fun and profit!
| SOLAR_FIELDS wrote:
| Falsehoods programmers believe about "falsehoods programmers
| believe" articles
| happytoexplain wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I honestly did not know a lot of things listed.
| BWStearns wrote:
| 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.
| lxgr wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 1/2 St". Imagine the problems of
| living at "123 1/2 43rd 1/2 St"!
| AndrewStephens wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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_.
| deathanatos wrote:
| > _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 wrote:
| > 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 wrote:
| 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.
| perrygeo wrote:
| https://www.972mag.com/the-worlds-only-ethnic-time-zone/
| theoriginaldave wrote:
| 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 wrote:
| But don't you have 01.00 - 02.00 EST and then 01.00 - 02.00
| EDT?
| theoriginaldave wrote:
| 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)
| foobarchu wrote:
| > 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.
| lxgr wrote:
| 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).
| madcaptenor wrote:
| Do Americans even know country calling codes exist?
| bxparks wrote:
| 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 wrote:
| 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 wrote:
| 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/meetingti
| me.html?iso=...)
| bee_rider wrote:
| 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.
| PaulDavisThe1st wrote:
| When you collect a time/date entry from a user, what are your
| instructions to them?
| LK5ZJwMwgBbHuVI wrote:
| <input type="datetime-local"> (plus some JS to turn it into a
| timestamp in UTC, since HTML is stupid)
| CWuestefeld wrote:
| 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 wrote:
| Unless it's MST and they live in Arizona
| manchmalscott wrote:
| 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.
| junar wrote:
| What happens if you try "my time" or "local time"?
| manchmalscott wrote:
| I guess we'll find out in March, that's a good question.
| foobarchu wrote:
| 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
| balderdash wrote:
| 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
| LK5ZJwMwgBbHuVI wrote:
| > 12:30 PM eastern to arizona
|
| 12:30 PM Tuesday, Eastern Time (ET) is 10:30 AM Tuesday, in
| Phoenix, AZ
| shagie wrote:
| 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 wrote:
| Every summer I take up this battle again. Don Quixote had a
| better shot with his windmills.
| maxwell wrote:
| Same, I used to dutifully shift my office hours between EST
| and EDT accordingly in my email signature.
| CWuestefeld wrote:
| I just use "ET", works all year.
| jrs235 wrote:
| That's what I do. ET, CT, MT, PT.
| jrs235 wrote:
| Can't one just write ET instead?
| theoriginaldave wrote:
| US ET
| madcaptenor wrote:
| 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.
| LK5ZJwMwgBbHuVI wrote:
| That's absolutely what standard time means. As opposed to local
| mean time. YOU are creating confusion.
| aksss wrote:
| 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 wrote:
| 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.
| madcaptenor wrote:
| 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).
| aorloff wrote:
| Everything happens in epochtime. How you want that displayed is
| up to you.
| dbrueck wrote:
| Unfortunately, this take is overly simplistic for a lot of
| scenarios (I'm looking at you, broadcast TV).
| PaulDavisThe1st wrote:
| But what about things that have already happened? Negative
| epochtime?
| aorloff wrote:
| Things that happened before 1970 ?
| PaulDavisThe1st wrote:
| Sure. When I want to reference a time before 1970 in a
| computer, how do I use epochtime? Just negative values?
| dbrueck wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Discussed at the time:
|
| _Falsehoods programmers believe about time zones_ -
| https://news.ycombinator.com/item?id=24870376 - Oct 2020 (16
| comments)
| hbn wrote:
| 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.
| LK5ZJwMwgBbHuVI wrote:
| > 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?
___________________________________________________________________
(page generated 2024-02-13 23:02 UTC)