One 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.)"
I'll add one: "But surely each place only has one DST each year…"
Nope. Troll Station in Antarctica has four different settings through the year.
Personally since there are only 40 people there I think they should just suck it up and pick two. They are probably causing a lot of software bugs. I know they cost me a couple hours.
Edit: Oh crum, I see Morocco suspends DST during Ramadan, so they have four settings too… and 33 million people. I can't ask that many people to change, it would take too long.
"I can't ask that many people to change, it would take too long."
Made my day.
There is this famous conversation-starter: "If you could enact one law, what would be it?" I always say that I would force the US to ditch imperial units, the Fahrenheit scale, and whatever other wonky specialties they've come up with that just confuse programmers everywhere.
Dealing 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):
Operating systems kind of suck at it. Which is why for Elixir I made Tzdata (https://github.com/lau/tzdata) not rely on any timezone information from the operating systems. A feature I would like from operating systems is to tell me the true time during leap seconds. E.g. 23:59:59, 23:59:60, 00:00:00 Instead of repeating 23:59:59 or just pretending the leap second never happens.
I 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.
MomentJS is great and offers pretty much everything you need time manipulation wise. That being said, I've spent many hours debugging problems with moment because many operations mutate the 'moment' instance that you're working with.
If you generate some moments and need to reuse them for multiple calculations, you need to constantly clone them.
I wish there was a moment-like library with good performance that's immutable.
Saw the title and came here to write about moment. I work on a large code base that had considerable amounts of code related to time conversions in numerous different places, each handled differently with different bugs, and I've slowly been moving things towards just using moment. It's been a huge time saver and has fixed issues everywhere I've ended up using. Probably one of the most useful libraries around for sure!
Another 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".
That is one of my all-time favorite youtube videos... This one, and a similar one on unicode[1], are my goto exhibits when I need to illustrate to a non-technical family member how much background complexity is involved in software
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.
Here in Germany (which once consisted of 100-or-so small states), the introduction of a unified timezone only happened when railroad systems were built, because people noticed for the first time that their clocks were off by a slight amount.
Until the unified timezone happened, timetables would be printed with multiple timezone information. So maybe your train would depart in Dresden at exactly 14:00 Saxonian time, take exactly three hours to drive to Berlin, and arrive there at 17:06 Prussian time.
Regarding daylight savings time, Arizona doesn't observe DST but the Navajo Nation region in Arizona does but inside that is a region that doesn't observe DST.
May I suggest adding "my users are in the same time zone as I am". Automated tests are often written with this implicit assumption too.
I recently fixed a bug for a local hire service I use frequently. I'd made the booking in Seattle, and they were 18 hours late when I got back to Melbourne...
Would it be too much to have a global movement for uniform time standards? No half-hour timezones, no daylight savings, no leap seconds, just easily predictable time. Calendars are supposed to be convenient, and right now our ancient conventions make it difficult to understand each other (not just computers; think of travelers having to adjust to timezones, "do I need DST or not?"). At least, lets think of the electricity consumed converting date structures.
PS. and while we re at it why not switch time to base-10? And seriously get rid of the imperial units already.
>We already do have a global standard time zone, and everybody who cares already uses it: UTC. There are also more accurate time standards in use for more specialist purposes.
* Time zone (/DST) changes are always announced well in advance.
* Time zone (/DST) changes are always announced in advance.
Yeah, so US announcing DST changes in 2005 that would take effect in 2007 is unusually long compared to most DST changes. A lot of Middle Eastern countries change DST based on the start of Ramadan, which doesn't officially start until someone actually observes the phase of the moon. While you could calculate this from well-known astronomical principles, there ends up being several different ways to handle corner cases which leads to several Islamic calendars in practice. This means that changes can end up being very last minute--a few years ago, the Olsen database wasn't updated for Egypt's DST changes until after they took effect, and there appears to have been a case or two in history where the actual official declaration of the change was, in effect, retroactive.
* 12 AM/12 PM are unambiguous.
* Days, weeks, months, and years all start on consistent patterns.
Well, everything is largely consistent in modern civil time reckoning based on the Gregorian calendar, but it's very definitely not the case if you look back as recently as a few decades ago or think about other times. Julian dates start at noon. Particularly in medieval times, the start of the year might be December 25 or March 25--and the time people switched to January 1 as the consistent start year wasn't necessarily the same as the switch from Julian to Gregorian calendars.
Time zones and DST are fun. When I worked at a healthcare software company, many hospitals chose to have their yearly upgrades done in the fall during the DST transition, because 1) it's confusing to see or even display documentation for events that happened at 2:30AM and the other 2:30AM and 2) it avoids any bugs that might crop up from the doubled hour.
My 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.
You are confusing two things. A time zone (e.g. Europe/London) is a geographical region of places always sharing the same time and it does not change at a given location unless time zones come and go. The zone time (e.g. GMT or BST) on the other hand is the time in use in a given time zone at a given point in time and it commonly changes twice a year between normal time and daylight saving time and back. In short, daylight saving time affects the zone time, not the time zone.
You are right. I have heard that one before too. That one is sort of implicitly covered by this part in the blog post:
"CST is also used for: Cuba Summer Time, China Time, Central Standard Time (Australia). PST is used for Pakistan Standard Time and Pacific Standard Time. If you want a unique identifier for the time zone in the Pacific West of the USA it looks like this: “America/Los_Angeles”."
In this case the name of the time zone "people live in" is "Europe/London", not GMT.
The way I get around this in my head is that UK's timezone is "Europe/London". (my definition of "timezone" is "IANA timezone", so while "UTC" or "GMT" are both valid, they aren't what the UK uses.) The "GMT" or "BST" is just a locale-ish thing that gets tacked on to output, much like "EST" or "EDT" for "America/New_York".
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.
A Book - "TIME – From Earth Rotation to Atomic Physics", by Dennis D. McCarthy and P. Kenneth Seidelmann, (Not a cheap book most places you can find it but it is worth it.)
The book left a permanent impression on me with respect to fundamentally understanding the physicality of time as an aspect of the universe we exist and are attempting to measure every time we record the time something takes to happen.
What 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.
This 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.
But Astronomers don't actually use "Civil Time" they tend to use either UTC, TAI, or for the continuation of record keeping over the last several hundred years... 'Terrestrial Time'...
None of which match up with any Civil Time anywhere on the world, except UTC which does so only periodically for some European countries, and year round in the following countries which resist the idiocy of shifting their clocks around based on the Season: Burkina Faso, Côte d'Ivoire, The Gambia, Ghana, Guinea, Guinea-Bissau, Liberia, Mali, Mauritania, Tomé and Príncipe, Senegal, Leone, Togo, Western Sahara (not technically a country but that's unrelated to the currently customary timezone), Greenland, Iceland, Saint Helena, Ascension Island and Tristan da Cunha
[+] [-] zensavona|10 years ago|reply
"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
[+] [-] laut|10 years ago|reply
I'm curious: Why where you using e.g. GMT+5 or GMT-5?
[+] [-] return0|10 years ago|reply
[+] [-] jws|10 years ago|reply
Nope. Troll Station in Antarctica has four different settings through the year.
Personally since there are only 40 people there I think they should just suck it up and pick two. They are probably causing a lot of software bugs. I know they cost me a couple hours.
Edit: Oh crum, I see Morocco suspends DST during Ramadan, so they have four settings too… and 33 million people. I can't ask that many people to change, it would take too long.
[+] [-] majewsky|10 years ago|reply
Made my day.
There is this famous conversation-starter: "If you could enact one law, what would be it?" I always say that I would force the US to ditch imperial units, the Fahrenheit scale, and whatever other wonky specialties they've come up with that just confuse programmers everywhere.
Also, let's get rid of DST entirely.
[+] [-] mistermann|10 years ago|reply
[+] [-] WalterBright|10 years ago|reply
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
[+] [-] ShrpErinaceidae|10 years ago|reply
1.3MB and it's actually raw code. Amazing.
[+] [-] laut|10 years ago|reply
[+] [-] crisnoble|10 years ago|reply
Timezones conversion is super hard, which is the exact reason I rely on libraries rather than trying to reinvent the wheel.
[+] [-] ShellfishMeme|10 years ago|reply
[+] [-] camhenlin|10 years ago|reply
[+] [-] Animats|10 years ago|reply
[1] https://bugs.python.org/issue15873
[+] [-] deathanatos|10 years ago|reply
Thankfully, there are third party libraries that do just this (such as iso8601), but its such a silly dependency to need.
[+] [-] x1798DE|10 years ago|reply
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".
[+] [-] bbody|10 years ago|reply
[+] [-] douche|10 years ago|reply
[1] https://www.youtube.com/watch?v=MijmeoH9LT4
[+] [-] v768|10 years ago|reply
[+] [-] majewsky|10 years ago|reply
Until the unified timezone happened, timetables would be printed with multiple timezone information. So maybe your train would depart in Dresden at exactly 14:00 Saxonian time, take exactly three hours to drive to Berlin, and arrive there at 17:06 Prussian time.
[+] [-] antod|10 years ago|reply
eg daylight savings is UTC+13:00 here.
[+] [-] pkaye|10 years ago|reply
[+] [-] fapjacks|10 years ago|reply
[+] [-] inopinatus|10 years ago|reply
I recently fixed a bug for a local hire service I use frequently. I'd made the booking in Seattle, and they were 18 hours late when I got back to Melbourne...
[+] [-] return0|10 years ago|reply
PS. and while we re at it why not switch time to base-10? And seriously get rid of the imperial units already.
[+] [-] Fuzzwah|10 years ago|reply
https://en.wikipedia.org/wiki/Swatch_Internet_Time
[+] [-] DanAndersen|10 years ago|reply
"So you want to abolish time zones" https://qntm.org/abolish
>We already do have a global standard time zone, and everybody who cares already uses it: UTC. There are also more accurate time standards in use for more specialist purposes.
"You advocate a ________ approach to calendar reform" https://qntm.org/calendar
These links helped convince me that while time zones and calendar systems are very messy, there are some inherent reasons why they are messy.
[+] [-] jcranmer|10 years ago|reply
* Time zone (/DST) changes are always announced well in advance. * Time zone (/DST) changes are always announced in advance.
Yeah, so US announcing DST changes in 2005 that would take effect in 2007 is unusually long compared to most DST changes. A lot of Middle Eastern countries change DST based on the start of Ramadan, which doesn't officially start until someone actually observes the phase of the moon. While you could calculate this from well-known astronomical principles, there ends up being several different ways to handle corner cases which leads to several Islamic calendars in practice. This means that changes can end up being very last minute--a few years ago, the Olsen database wasn't updated for Egypt's DST changes until after they took effect, and there appears to have been a case or two in history where the actual official declaration of the change was, in effect, retroactive.
* 12 AM/12 PM are unambiguous. * Days, weeks, months, and years all start on consistent patterns.
Well, everything is largely consistent in modern civil time reckoning based on the Gregorian calendar, but it's very definitely not the case if you look back as recently as a few decades ago or think about other times. Julian dates start at noon. Particularly in medieval times, the start of the year might be December 25 or March 25--and the time people switched to January 1 as the consistent start year wasn't necessarily the same as the switch from Julian to Gregorian calendars.
[+] [-] epmatsw|10 years ago|reply
[+] [-] cle|10 years ago|reply
Days don't always start at midnight.
Midnight might not exist--some countries perform their DST transition at midnight, so the clock goes from 11:59 PM to 1:00 AM. Fun stuff!
[+] [-] timthorn|10 years ago|reply
[+] [-] danbruc|10 years ago|reply
[+] [-] laut|10 years ago|reply
"CST is also used for: Cuba Summer Time, China Time, Central Standard Time (Australia). PST is used for Pakistan Standard Time and Pacific Standard Time. If you want a unique identifier for the time zone in the Pacific West of the USA it looks like this: “America/Los_Angeles”."
In this case the name of the time zone "people live in" is "Europe/London", not GMT.
[+] [-] deathanatos|10 years ago|reply
[+] [-] theoh|10 years ago|reply
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.
[+] [-] techdragon|10 years ago|reply
Two of the best resources on this topic that I've come across are:
A PyCon presentation - "Blame It On Ceasar" https://www.youtube.com/watch?v=GBKqRhn0ekM
A Book - "TIME – From Earth Rotation to Atomic Physics", by Dennis D. McCarthy and P. Kenneth Seidelmann, (Not a cheap book most places you can find it but it is worth it.)
The book left a permanent impression on me with respect to fundamentally understanding the physicality of time as an aspect of the universe we exist and are attempting to measure every time we record the time something takes to happen.
[+] [-] detaro|10 years ago|reply
[+] [-] x1798DE|10 years ago|reply
[+] [-] voltagex_|10 years ago|reply
[+] [-] CarolineW|10 years ago|reply
https://news.ycombinator.com/item?id=4128208
[+] [-] 9mit3t2m9h9a|10 years ago|reply
Wrong, Russia has combined some timezones into a single one and then has split it back a few years later.
[+] [-] MichaelGG|10 years ago|reply
[+] [-] techdragon|10 years ago|reply
None of which match up with any Civil Time anywhere on the world, except UTC which does so only periodically for some European countries, and year round in the following countries which resist the idiocy of shifting their clocks around based on the Season: Burkina Faso, Côte d'Ivoire, The Gambia, Ghana, Guinea, Guinea-Bissau, Liberia, Mali, Mauritania, Tomé and Príncipe, Senegal, Leone, Togo, Western Sahara (not technically a country but that's unrelated to the currently customary timezone), Greenland, Iceland, Saint Helena, Ascension Island and Tristan da Cunha
[+] [-] laut|10 years ago|reply