Trivia questions, easily answered by programmers who appreciate the subtleties of time math:<p>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.)<p>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.)<p>It's my experience that when the programmers get date math <i>correct</i>, they may still find themselves fielding "bug" reports from enterprise customers who <i>should</i> 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).
I watch Tom Scott's "The Problem WIth Time And Time Zones" from time to time just as a reminder<p><a href="https://www.youtube.com/watch?v=-5wpm-gesOY" rel="nofollow">https://www.youtube.com/watch?v=-5wpm-gesOY</a>
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.
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: <a href="https://discussions.apple.com/thread/179539" rel="nofollow">https://discussions.apple.com/thread/179539</a>
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.<p>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.
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).
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.<p>Time is not just calendar apps, or cron. Consider relative dates in historical studies that span past, present and future.<p>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.<p>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.<p><a href="http://www.worldcat.org/search?qt=worldcat_org_all&q=calendrical+calculations" rel="nofollow">http://www.worldcat.org/search?qt=worldcat_org_all&q=calendr...</a>
I find most people doen't understand the difference between timezone and time offset.<p>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.<p>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.
According to cron's man page on Debian the "fix" that makes cron work on DST is "Debian specific". What happens on other distributions?<p>On Debian:
<a href="http://debian-handbook.info/browse/stable/sect.task-scheduling-cron-atd.html#idm139883800332112" rel="nofollow">http://debian-handbook.info/browse/stable/sect.task-scheduli...</a>
I'm pretty sure we had a big discussion on this a couple of months ago, but I cannot find the link.<p>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.
This was our topic from our local dev meetup last month. We have a video of it here: <a href="https://www.youtube.com/watch?v=ZQAELeiY68E" rel="nofollow">https://www.youtube.com/watch?v=ZQAELeiY68E</a>. Interesting discussion of weird time bugs too.
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 <i>floating</i> datetimes at the same time.
Its not just your code that needs timezone awareness, users are all shockingly bad at understanding timezones. Daylight savings in particular needs to die.