9 ms·

The need for timezone awareness

52 points by laut 11y ago

Roritharr 11y ago
Living in germany I often times have to raise eyebrows at the basic assumptions american coders often have with regards to encoding, timezone awareness and other common defaults. An american friend with french heritage noticed happily after moving to germany that the accent de gue on his last name was finally printed correctly on his mail and packages.
- maljx 11y ago
  Lets not get carried away - everyone in Germany misspells my Swedish first name. (Because I use a spelling that is not used in Germany everyone here "corrects" my name, even when I enter myself it on websites, etc.)
  - Roritharr 11y ago
    I'm not saying we're beyond error, but atleast the input field didn't force you to change the letter or throw an error otherwise. ;)
  - rogerbinns 11y ago
    My French friend Stéphane (male) had a lot of trouble in the US. A very large number of sites and services don't let you enter the accent. Many places that had any kind of the human in the loop would also "correct" his gender to female and name to Stephanie.
- kristiandupont 11y ago
  Actually I (as a Dane) feel that we are all fortunate because the US is in multiple timezones. Had one of the small single-timezone countries headed the IT revolution, we would surely have much greater problems, similar to the way ascii still lives on in systems where it clearly shouldn't.
  - thecodemonkey 11y ago
    As a Dane now living in the US. All apps I'm building now has a US-audience which means that they have to be timezone aware per default as opposed to apps with a danish audience where I didn't have to be concerned about timezones. The truth is, timezones are a pain.
- leni536 11y ago
  Many of my collages use the unaccented version of their names just to avoid complications. I use my accents whenever it's possible though.
firegrind 11y ago
I watch Tom Scott's "The Problem WIth Time And Time Zones" from time to time just as a reminder https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
- laut 11y ago
  It is a good video. The good thing about using a library like Kalends is that it takes into account everything he mentions about different timezones into account. Just tell it the time, date, and timezone name. Just be careful about generalizing too much and assuming things such as: "this time will exist again tomorrow". Or "next month also has a 31st day". Or "DST is always a 3600 second difference from standard time". Here is another article I wrote which also talks about some pitfalls of time and timezones: http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
oulipian 11y ago
Try living in a time zone that is a half-hour deviation from standard time (Newfoundland & Labrador). When I first got an iPod my time zone simply wasn't supported by the software: https://discussions.apple.com/thread/179539 https://discussions.apple.com/thread/179539
- NKCSS 11y ago
  Try living in Nepal [0] ;) [0] http://www.timeanddate.com/worldclock/nepal/kathmandu http://www.timeanddate.com/worldclock/nepal/kathmandu
  - ceejayoz 11y ago
    My favorite is Amsterdam Time. http://en.wikipedia.org/wiki/UTC%2B00:20 http://en.wikipedia.org/wiki/UTC%2B00:20 > The exact timezone was GMT +0h 19m 32.13s until March 17, 1937... Yes, 32.13 seconds.
    - rs232 11y ago
      Wow, TIL. Any idea why?
      - colefichter 11y ago
        Every town used to have their own local time based on the sun being at zenith at local noon. For example, a place like Oxford would be a few minutes behind London. With the advent of railways, it became necessary to standardize things a bit. You can imagine the difficulty if each town a train stopped in had its own timezone! There's an interesting podcast from BBC that covers this: http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OIO-X92mZz6Q http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OI...
      - wodenokoto 11y ago
        I'm just speculating, but maybe that is the actual time difference from Greenwich.
      - 11y ago
Olap84 11y ago
Its not just your code that needs timezone awareness, users are all shockingly bad at understanding timezones. Daylight savings in particular needs to die.
- robmcm 11y ago
  I think a more considered way to say that is it's a UX challange. You have to think about what the user want's to enter and what they want to see. It's especially hard if they are doing something like booking a flight, or car hire in another country, how do you know if they are thinking about local time or destination time?
- gutnor 11y ago
  The hardest I have noticed is to make them understand that it is not only the time, but also the date that change. So when discussing whole timestamp or time - everybody is somewhat aware there is going to be timezone involved. Good luck however, if you need to ask the question: "Is the instruction date (yyyy-mm-dd) in the Counterparty (Sidney), Party (London) or System timezone (Brussels) ?"
lorenzfx 11y ago
Even when using a library that supports timezones (and DST), handling them is still a pain, especially if one has to deal with timezone aware and floating datetimes at the same time.
loudmax 11y ago
In my experience, the simplest way to program with times and dates is nearly always to convert to Unix epoch as early as you can in the process. Do all processing in Epoch, then convert back to something readable by humans at the last possible moment. This approach won't work in all circumstances, but it should be the standard approach unless there's a compelling reason not to.
- Rapzid 11y ago
  I agree on the point of always be converting, but I'll settle with UTC. IMHO if you have a non-utc time one if two things should happen: A.) Convert it to Utc. B.) Show it to someone. Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.
  - laut 11y ago
    Here is an example where the "convert it to UTC" rule would fail: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future... I will stick non-UTC time into the database and I made a library to do it.
    - robmcm 11y ago
      I'm not sure I understand the point of saving the offset: "To avoid ambigiuty we also save a third piece of data: the UTC offset. Note that the UTC offset is only there for the rare cases when the timezone does not change, but when there is an ambiguity we know about at scheduling time - that will usually be when the timezone goes off of DST and a range of time (usually an hour) happens twice in autumn when clocks are set back. In this example though this third piece of data is not used for anything." This doesn't make sense to me? Great read otherwise. I hadn't considered this edge case!
      - laut 11y ago
        The reason the offset is changed is ambigous datetimes that occur when going off of DST. Let us say a user enters a datetime in the autumn. It happens to be a few minutes after the clocks are set back an hour. So the time is ambiguous. Which datetime exactly does the user want? The one before or after the clocks are set back? We show him a dialog and he chooses one. To differentiate we use the standard offset which is usally 0 or 3600 seconds. Great, now we save it to the database as just wall time and timezone name and load it again. How do we know if it is 02:05 before the clocks are set back or 02:05 after the clocks are set back? We don't, unless we saved the UTC offset. But if we save the offset we know exactly which one it is. But we don't want to use the offset we calculated from the beginning. That would get us the same error as if saving just the UTC time. So we only use the offset if we absolutely have to. This is what Kalecto does when loading a saved datetime from the library: we do the calculation based on the saved "wall time" and the timezone name. If that wall time is ambiguous we use the UTC offset. If there were no changes to the rules for that timezone - no problems. Now, if we have a combination of the timezone rules changing and the saved datetime being ambiguous, the entered choice is no longer valid. We have to ask the user again or report an error. I hope this explains it better.
azurelogic 11y ago
This was our topic from our local dev meetup last month. We have a video of it here: https://www.youtube.com/watch?v=ZQAELeiY68E https://www.youtube.com/watch?v=ZQAELeiY68E. Interesting discussion of weird time bugs too.
lucb1e 11y ago
Well that answers the question I've been asking people for years: why do people keep using PST when everyone in the world understands UTC+/-X but nobody has a timezone table in their heads? Well, timezones change (using summertime or not changes the most).
- realusername 11y ago
  I was also thinking the same thing, I have to Google this kind of things all the time, acronyms like this are absolutely not useful at all to determine the exact time things are going to run.
- chimeracoder 11y ago
  > why do people keep using PST Especially when, for most of the year, even the US west coast doesn't use PST (they use PDT). You may think I'm being pedantic, but most naive timezone conversion tools won't pick up this error for you, if you ask them to convert "1PM in PST to my local time". I once ended up on a conference call at the right time by myself because the other party assumed that London time was the same as UTC (it's not - they were in Daylight Saving Time, so they were an hour ahead).
protomyth 11y ago
I'm pretty sure we had a big discussion on this a couple of months ago, but I cannot find the link. Don't forget that for a lot of applications your users don't care about time zones. "I have a meeting every Monday morning at 10:00AM and some folks from around the world call in". Its up the the programmer to figure that out for all involved.
robmcm 11y ago
I find most people doen't understand the difference between timezone and time offset. I reciently had a huge issue trying to explain to people why we couldn't (easily) show the offset next to the city on a date time input, because we didn't have a native library to do it. They couldn't grasp that a date in the future could have a different offset for the same city and that they didn't all change at the same time. If anyone is using JS checkout moment.js and also be aware that date objects in most client side runtimes are in the users timezone by default, and often doen't let you change the offset.
leni536 11y ago
According to cron's man page on Debian the "fix" that makes cron work on DST is "Debian specific". What happens on other distributions? On Debian: http://debian-handbook.info/browse/stable/sect.task-scheduling-cron-atd.html#idm139883800332112 http://debian-handbook.info/browse/stable/sect.task-scheduli...
- Ded7xSEoPKYNsDd 11y ago
  Fedora uses cronie as crond, which does something similar: https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8#n112 https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8...
- laut 11y ago
  You could the server timezone to UTC to avoid those problems.
emptybits 11y ago
Trivia questions, easily answered by programmers who appreciate the subtleties of time math: 1. If someone leaves Vancouver at 1 am and arrives in Seattle at 4 am on the same day, and you know the distance they travelled is 240 km, what was their average rate of speed? (Correct answer: 120 km/h, 80 km/h, or 60 km/h, depending on what day it is. UTC storage helps here.) 2. If it's noon in Vancouver, what time is it in London, England? (Correct answer: 7 pm, 8 pm, or 9 pm, depending on what day it is. Knowledge of regional DST schedule differences helps here.) It's my experience that when the programmers get date math correct, they may still find themselves fielding "bug" reports from enterprise customers who should understand the concept but don't (particularly if their business is billing or rate calculation -- think of short term billing for hourly parking or CPU hours as an example).
- apaprocki 11y ago
  3. How many simultaneous "days" are active at any given time on Earth? (3; 11pm Wednesday on Baker Island is 11am Thursday in London and 1am Friday in Kiribati)
  - paublyrne 11y ago
    Of course that's not at 'any' given time. That is only between 10am and 11.59am GMT each day.
a3n 11y ago
Time is huge. You cannot get it right in all cases. You can only get it right for your particular case. If you try to get it right for all cases, you waste resources on something that mostly doesn't matter, and dwarf your other resources. Time is not just calendar apps, or cron. Consider relative dates in historical studies that span past, present and future. Study the fuck out of your use case, get it right, don't worry about others' opinions and don't think that your solution applies generally to most other use cases. Also, among the many resources for general and specific solutions to time problems is "Calendrical Calculations," by Dershowitz and Reingold. I found it randomly, bought it on a lark, and hope to $DEITY I never haver to care about time for anything critical. http://www.worldcat.org/search?qt=worldcat_org_all&q=calendrical+calculations http://www.worldcat.org/search?qt=worldcat_org_all&q=calendr...
- davotoula 11y ago
  $265.90 Bought it on a lark??
  - mordocai 11y ago
    $39.59 on amazon for the paperback, new. $116.90 on amazon for the hardcover, new.
  - a3n 11y ago
    Really? Wow. I was cruising the shelves of SoftPro books (back when they had shelves and a physical presence). The sticker on my copy says $32.99. Well, the link I provided was to a worldwide library catalog, you should be able to interlibrary loan it to your branch if you're interested. Or you can get a copy on Abe Books for pretty cheap. http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calendrical+calculations http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calen... But no, my upper lark limit is considerably lower than $265.90. :)
  - deleted 11y ago
    [deleted]

52 points by laut 11y ago

Living in germany I often times have to raise eyebrows at the basic assumptions american coders often have with regards to encoding, timezone awareness and other common defaults. An american friend with french heritage noticed happily after moving to germany that the accent de gue on his last name was finally printed correctly on his mail and packages.

maljx 11y ago
Lets not get carried away - everyone in Germany misspells my Swedish first name. (Because I use a spelling that is not used in Germany everyone here "corrects" my name, even when I enter myself it on websites, etc.)
- Roritharr 11y ago
  I'm not saying we're beyond error, but atleast the input field didn't force you to change the letter or throw an error otherwise. ;)
- rogerbinns 11y ago
  My French friend Stéphane (male) had a lot of trouble in the US. A very large number of sites and services don't let you enter the accent. Many places that had any kind of the human in the loop would also "correct" his gender to female and name to Stephanie.
kristiandupont 11y ago
Actually I (as a Dane) feel that we are all fortunate because the US is in multiple timezones. Had one of the small single-timezone countries headed the IT revolution, we would surely have much greater problems, similar to the way ascii still lives on in systems where it clearly shouldn't.
- thecodemonkey 11y ago
  As a Dane now living in the US. All apps I'm building now has a US-audience which means that they have to be timezone aware per default as opposed to apps with a danish audience where I didn't have to be concerned about timezones. The truth is, timezones are a pain.
leni536 11y ago
Many of my collages use the unaccented version of their names just to avoid complications. I use my accents whenever it's possible though.

firegrind 11y ago

I watch Tom Scott's "The Problem WIth Time And Time Zones" from time to time just as a reminder https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY

laut 11y ago
It is a good video. The good thing about using a library like Kalends is that it takes into account everything he mentions about different timezones into account. Just tell it the time, date, and timezone name. Just be careful about generalizing too much and assuming things such as: "this time will exist again tomorrow". Or "next month also has a 31st day". Or "DST is always a 3600 second difference from standard time". Here is another article I wrote which also talks about some pitfalls of time and timezones: http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

oulipian 11y ago

Try living in a time zone that is a half-hour deviation from standard time (Newfoundland & Labrador). When I first got an iPod my time zone simply wasn't supported by the software: https://discussions.apple.com/thread/179539 https://discussions.apple.com/thread/179539

NKCSS 11y ago
Try living in Nepal [0] ;) [0] http://www.timeanddate.com/worldclock/nepal/kathmandu http://www.timeanddate.com/worldclock/nepal/kathmandu
- ceejayoz 11y ago
  My favorite is Amsterdam Time. http://en.wikipedia.org/wiki/UTC%2B00:20 http://en.wikipedia.org/wiki/UTC%2B00:20 > The exact timezone was GMT +0h 19m 32.13s until March 17, 1937... Yes, 32.13 seconds.
  - rs232 11y ago
    Wow, TIL. Any idea why?
    - colefichter 11y ago
      Every town used to have their own local time based on the sun being at zenith at local noon. For example, a place like Oxford would be a few minutes behind London. With the advent of railways, it became necessary to standardize things a bit. You can imagine the difficulty if each town a train stopped in had its own timezone! There's an interesting podcast from BBC that covers this: http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OIO-X92mZz6Q http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OI...
    - wodenokoto 11y ago
      I'm just speculating, but maybe that is the actual time difference from Greenwich.
    - 11y ago

Olap84 11y ago

Its not just your code that needs timezone awareness, users are all shockingly bad at understanding timezones. Daylight savings in particular needs to die.

robmcm 11y ago
I think a more considered way to say that is it's a UX challange. You have to think about what the user want's to enter and what they want to see. It's especially hard if they are doing something like booking a flight, or car hire in another country, how do you know if they are thinking about local time or destination time?
gutnor 11y ago
The hardest I have noticed is to make them understand that it is not only the time, but also the date that change. So when discussing whole timestamp or time - everybody is somewhat aware there is going to be timezone involved. Good luck however, if you need to ask the question: "Is the instruction date (yyyy-mm-dd) in the Counterparty (Sidney), Party (London) or System timezone (Brussels) ?"

lorenzfx 11y ago

Even when using a library that supports timezones (and DST), handling them is still a pain, especially if one has to deal with timezone aware and floating datetimes at the same time.

loudmax 11y ago

In my experience, the simplest way to program with times and dates is nearly always to convert to Unix epoch as early as you can in the process. Do all processing in Epoch, then convert back to something readable by humans at the last possible moment. This approach won't work in all circumstances, but it should be the standard approach unless there's a compelling reason not to.

Rapzid 11y ago
I agree on the point of always be converting, but I'll settle with UTC. IMHO if you have a non-utc time one if two things should happen: A.) Convert it to Utc. B.) Show it to someone. Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.
- laut 11y ago
  Here is an example where the "convert it to UTC" rule would fail: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future... I will stick non-UTC time into the database and I made a library to do it.
  - robmcm 11y ago
    I'm not sure I understand the point of saving the offset: "To avoid ambigiuty we also save a third piece of data: the UTC offset. Note that the UTC offset is only there for the rare cases when the timezone does not change, but when there is an ambiguity we know about at scheduling time - that will usually be when the timezone goes off of DST and a range of time (usually an hour) happens twice in autumn when clocks are set back. In this example though this third piece of data is not used for anything." This doesn't make sense to me? Great read otherwise. I hadn't considered this edge case!
    - laut 11y ago
      The reason the offset is changed is ambigous datetimes that occur when going off of DST. Let us say a user enters a datetime in the autumn. It happens to be a few minutes after the clocks are set back an hour. So the time is ambiguous. Which datetime exactly does the user want? The one before or after the clocks are set back? We show him a dialog and he chooses one. To differentiate we use the standard offset which is usally 0 or 3600 seconds. Great, now we save it to the database as just wall time and timezone name and load it again. How do we know if it is 02:05 before the clocks are set back or 02:05 after the clocks are set back? We don't, unless we saved the UTC offset. But if we save the offset we know exactly which one it is. But we don't want to use the offset we calculated from the beginning. That would get us the same error as if saving just the UTC time. So we only use the offset if we absolutely have to. This is what Kalecto does when loading a saved datetime from the library: we do the calculation based on the saved "wall time" and the timezone name. If that wall time is ambiguous we use the UTC offset. If there were no changes to the rules for that timezone - no problems. Now, if we have a combination of the timezone rules changing and the saved datetime being ambiguous, the entered choice is no longer valid. We have to ask the user again or report an error. I hope this explains it better.

azurelogic 11y ago

This was our topic from our local dev meetup last month. We have a video of it here: https://www.youtube.com/watch?v=ZQAELeiY68E https://www.youtube.com/watch?v=ZQAELeiY68E. Interesting discussion of weird time bugs too.

lucb1e 11y ago

Well that answers the question I've been asking people for years: why do people keep using PST when everyone in the world understands UTC+/-X but nobody has a timezone table in their heads? Well, timezones change (using summertime or not changes the most).

realusername 11y ago
I was also thinking the same thing, I have to Google this kind of things all the time, acronyms like this are absolutely not useful at all to determine the exact time things are going to run.
chimeracoder 11y ago
> why do people keep using PST Especially when, for most of the year, even the US west coast doesn't use PST (they use PDT). You may think I'm being pedantic, but most naive timezone conversion tools won't pick up this error for you, if you ask them to convert "1PM in PST to my local time". I once ended up on a conference call at the right time by myself because the other party assumed that London time was the same as UTC (it's not - they were in Daylight Saving Time, so they were an hour ahead).

protomyth 11y ago

I'm pretty sure we had a big discussion on this a couple of months ago, but I cannot find the link. Don't forget that for a lot of applications your users don't care about time zones. "I have a meeting every Monday morning at 10:00AM and some folks from around the world call in". Its up the the programmer to figure that out for all involved.

robmcm 11y ago

I find most people doen't understand the difference between timezone and time offset. I reciently had a huge issue trying to explain to people why we couldn't (easily) show the offset next to the city on a date time input, because we didn't have a native library to do it. They couldn't grasp that a date in the future could have a different offset for the same city and that they didn't all change at the same time. If anyone is using JS checkout moment.js and also be aware that date objects in most client side runtimes are in the users timezone by default, and often doen't let you change the offset.

leni536 11y ago

According to cron's man page on Debian the "fix" that makes cron work on DST is "Debian specific". What happens on other distributions? On Debian: http://debian-handbook.info/browse/stable/sect.task-scheduling-cron-atd.html#idm139883800332112 http://debian-handbook.info/browse/stable/sect.task-scheduli...

Ded7xSEoPKYNsDd 11y ago
Fedora uses cronie as crond, which does something similar: https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8#n112 https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8...
laut 11y ago
You could the server timezone to UTC to avoid those problems.

emptybits 11y ago

Trivia questions, easily answered by programmers who appreciate the subtleties of time math: 1. If someone leaves Vancouver at 1 am and arrives in Seattle at 4 am on the same day, and you know the distance they travelled is 240 km, what was their average rate of speed? (Correct answer: 120 km/h, 80 km/h, or 60 km/h, depending on what day it is. UTC storage helps here.) 2. If it's noon in Vancouver, what time is it in London, England? (Correct answer: 7 pm, 8 pm, or 9 pm, depending on what day it is. Knowledge of regional DST schedule differences helps here.) It's my experience that when the programmers get date math correct, they may still find themselves fielding "bug" reports from enterprise customers who should understand the concept but don't (particularly if their business is billing or rate calculation -- think of short term billing for hourly parking or CPU hours as an example).

apaprocki 11y ago
3. How many simultaneous "days" are active at any given time on Earth? (3; 11pm Wednesday on Baker Island is 11am Thursday in London and 1am Friday in Kiribati)
- paublyrne 11y ago
  Of course that's not at 'any' given time. That is only between 10am and 11.59am GMT each day.

a3n 11y ago

Time is huge. You cannot get it right in all cases. You can only get it right for your particular case. If you try to get it right for all cases, you waste resources on something that mostly doesn't matter, and dwarf your other resources. Time is not just calendar apps, or cron. Consider relative dates in historical studies that span past, present and future. Study the fuck out of your use case, get it right, don't worry about others' opinions and don't think that your solution applies generally to most other use cases. Also, among the many resources for general and specific solutions to time problems is "Calendrical Calculations," by Dershowitz and Reingold. I found it randomly, bought it on a lark, and hope to $DEITY I never haver to care about time for anything critical. http://www.worldcat.org/search?qt=worldcat_org_all&q=calendrical+calculations http://www.worldcat.org/search?qt=worldcat_org_all&q=calendr...

davotoula 11y ago
$265.90 Bought it on a lark??
- mordocai 11y ago
  $39.59 on amazon for the paperback, new. $116.90 on amazon for the hardcover, new.
- a3n 11y ago
  Really? Wow. I was cruising the shelves of SoftPro books (back when they had shelves and a physical presence). The sticker on my copy says $32.99. Well, the link I provided was to a worldwide library catalog, you should be able to interlibrary loan it to your branch if you're interested. Or you can get a copy on Abe Books for pretty cheap. http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calendrical+calculations http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calen... But no, my upper lark limit is considerably lower than $265.90. :)
- deleted 11y ago
  [deleted]