Falsehoods programmers believe about time and time zones
creativedeletion.com
Falsehoods programmers believe about time and time zones
1–10 of 83 posts
Re: Falsehoods programmers believe about time and time zones
#2What 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.
Re: Falsehoods programmers believe about time and time zones
#3What 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.
It's extra tough to know what to do on that situation if you don't know the provenance of the timestamp, because there are some programs that output timestamps formatted like a POSIX TZ, but with the opposite sign convention.
Re: Falsehoods programmers believe about time and time zones
#4Another thing to consider is that transitions in offset are not always tied to transitions in DST, and you can (rarely) get transitions in DST that do not involve an offset change. For example, Portugal changed their base zone to Western European Time from Central European Time during a scheduled DST transition. The result was that they switched over to being in "Summer Time" with no change in the clocks.
There are also examples of non-DST related time zone changes of up to 24 hours (mostly from Pacific islands deciding to change what side of the international date line they are on), so in some zones, there are certain entire days that never happened (e.g. the entire day is an "imaginary day") and some that happened "twice".
Re: Falsehoods programmers believe about time and time zones
#5What 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.
It's extra tough to know what to do on that situation if you don't know the provenance of the timestamp, because there are some programs that output timestamps formatted like a POSIX TZ, but with the opposite sign convention.
Indeed. If you just have a random timestamp, no clue what it is. Another reason why you should generate ISO 8601 timestamps if possible, but they are not so nice for humans reading (or even worse, writing) them.
Re: Falsehoods programmers believe about time and time zones
#6I hope http://momentjs.com/ is not one of libraries that falls into "Many people write libraries without knowing much about the domain." I have used it many times and it is the best one I have come across.
Timezones conversion is super hard, which is the exact reason I rely on libraries rather than trying to reinvent the wheel.
Re: Falsehoods programmers believe about time and time zones
#7* Time zones and Date Arithmetic are a complete and utter shitshow.
Actually this isn't a falsehood, this is true.
Re: Falsehoods programmers believe about time and time zones
#8Might I refer the interested reader to a lengthy discussion about this topic from 1399 days ago:
Re: Falsehoods programmers believe about time and time zones
#9Dealing 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):
Re: Falsehoods programmers believe about time and time zones
#10My 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.