I would add most programmers don't know some time zones have offsets in minutes. In ancient times, some were in seconds.
I live in UTC-04:30 and regularly encounter bugs because of it.
Falsehoods programmers believe about time and time zones
11–20 of 83 posts
Re: Falsehoods programmers believe about time and time zones
#12This is why we should ignore time zones as much as possible. UTC is almost OK, except for the shitshow idiocy of leap seconds. There's no reason for all of us to suffer just so astronomers can use civil time.
Re: Falsehoods programmers believe about time and time zones
#13In 2012, I submitted a Python bug about the bad state of ISO 8601 date parsing in Python. It's still open, after four years of arguments.[1]
Re: Falsehoods programmers believe about time and time zones
#14I would add most programmers don't know some time zones have offsets in minutes. In ancient times, some were in seconds. I live in UTC-04:30 and regularly encounter bugs because of it.
Or that +/-12hrs is enough offset for everyone.
eg daylight savings is UTC+13:00 here.
Re: Falsehoods programmers believe about time and time zones
#15One of the more interesting bugs I've created is in an Elixir program using the (great) Timex[0] library. I realised that for a few particular users, timezones were being inverted when converted (e.g. a user in GMT+5 would behave as if they were in GMT-5 and vice versa). After a lot of time spent proving to myself I was not actually going mad, I opened a Github issue and the library author informed me about one of the stranger quirks of timezones - the Etc/UTC-X timezones[1], which represent areas that don't have an assigned area (usually a continent, like Europe/Berlin).
"The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead/east of GMT.)"
[0] https://github.com/bitwalker/timex [1] https://en.wikipedia.org/wiki/Tz_database#Area
Re: Falsehoods programmers believe about time and time zones
#16My bete noir isn't in the list: GMT is only the UK timezone for about half the year. During the Summer, GMT continues to exist, but the UK time is BST.
But, as the Wikipedia page says "the term GMT should not be used for precise purposes" as it has been superseded by various other standards (e.g. UTC, UT1)
I've encountered English people who made a fuss about the loss of "God's Magnificent Time", but for better or worse GMT is no longer the official name.
Re: Falsehoods programmers believe about time and time zones
#17* If I know the country and the timezone, I can automatically apply all the future timezone changes
Wrong, Russia has combined some timezones into a single one and then has split it back a few years later.
Re: Falsehoods programmers believe about time and time zones
#18Dealing with timezones and daylight savings time has consumed hundreds of hours of my development time. This seriously should be a standard service of the operating system, not the programming language library. Just look at all the code to deal with it in D (written by Jonathan Davis): https://github.com/dlang/phobos/blob/master/std/datetime.d
"(Sorry about that, but we can’t show files that are this big right now.)"
1.3MB and it's actually raw code. Amazing.
Re: Falsehoods programmers believe about time and time zones
#19It bothers me that a minute is not always 60 seconds. For leap seconds why did we choose 23:59:60 instead of 24:00:00? If we had went with the latter we also solve the daylight savings time problem. A day would last until 22:59:59 or 24:59:59 depending on the time of year. It seems like a lot of things would be simpler that way. Does anyone have a better understanding of why things ended up this way?
Re: Falsehoods programmers believe about time and time zones
#20What surprised me the most recently was that POSIX specifies timezone offsets the other way round from the rest of the world, and thus many parsing libraries will interpret something like "2016-1-1 12:00:00 GMT+2" as 14:00 in UTC, instead of 10:00.
Oh no, GMT+2 means subtract two hours? How does that work?