Of all things that are troublesome when it comes to building software products, time is the hydra that keeps raising a head over and over. I've lost count of the gotchas that come with the question of "what time is it?".<p>In complete seriousness, I hope a time comes eventually where cosmology has advanced to a point where we have a measurement of current time relative to the Big Bang accurate to the nano second. Given issues of relativity and such, it would be a value only local to us, but that's more than fine. When we start hashing out time values with aliens, that will be a different problem.
This is why you always normalize your timestamps to UTC for storage/logging. To explain in a bit more detail, here's a thought experiment. You are in California, and it's 2012-11-04 1:30 AM. You need to save this time to refer to it later (pick your favorite reason).<p>If you assume you are storing times in your time zone, why can't you determine the correct time the timestamp refers to at a later date?<p>Why is your location important?
There's much more simpler (and relevant) ways to break date logic than going back to 1927. Take for instance:<p><pre><code> var d = new Date(2013, 9, 20);
</code></pre>
For 200 million people in the world, d.getDate() will be 19.<p>Now, are you sure your app doesn't break when that happens?
I've always loved date-time problems because it's one of those things that seems straightforward and simple, but when you drill down into it, turns out to be devilishly hard. It's made me think twice anytime I want to jump to the conclusion that something is "simple".
It seems wrong, or VB-ish, to assume the local system settings for things such as parsing. Shouldn't the default be to use UTC, and then force developers to opt-in to "whatever the user currently has"? Or at force parseUtc or parseLocal? I understand that there's an argument for doing what the programmer probably has in mind, but in too many cases, the programmer hasn't even thought of that.<p>The fact you could run this, take a flight somewhere, run it again and get totally different results seems unsettling. (Same thing applies to numeric parsing/display functions.)<p>I ran into one customer having problems authenticating to our service; turns out his clocks were on local time, not UTC. He seemed upset about that, until I pointed out that his billing records will get an extra hour, or go negative, during DST transitions. Changed his tune pretty quickly.<p>Another customer handled it a different way: "Oh, the platform we use crashes when a time transition occurs, so we never generate records spanning such times."
Shameless plug: If your webapp deals with date, time and timezones in the past, present or future, you may want to use TimeNinja[0] - a simple, free REST API, I built, for date time conversion and arithmetic which uses historical timezone information to perform required calculations.<p>[0] <a href="http://www.timeninja.net" rel="nofollow">http://www.timeninja.net</a>