Why does subtracting these two times give a strange result? (2011)

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&#x27;ve lost count of the gotchas that come with the question of &quot;what time is it?&quot;.<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&#x27;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&#x2F;logging. To explain in a bit more detail, here&#x27;s a thought experiment. You are in California, and it&#x27;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&#x27;t you determine the correct time the timestamp refers to at a later date?<p>Why is your location important?

There&#x27;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&#x27;t break when that happens?

I&#x27;ve always loved date-time problems because it&#x27;s one of those things that seems straightforward and simple, but when you drill down into it, turns out to be devilishly hard. It&#x27;s made me think twice anytime I want to jump to the conclusion that something is &quot;simple&quot;.

It seems wrong, or VB-ish, to assume the local system settings for things such as parsing. Shouldn&#x27;t the default be to use UTC, and then force developers to opt-in to &quot;whatever the user currently has&quot;? Or at force parseUtc or parseLocal? I understand that there&#x27;s an argument for doing what the programmer probably has in mind, but in too many cases, the programmer hasn&#x27;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&#x2F;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: &quot;Oh, the platform we use crashes when a time transition occurs, so we never generate records spanning such times.&quot;

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:&#x2F;&#x2F;www.timeninja.net</a>

I feel like the perseon who answered this question is the same person who asked it. How could anyone stumble across this error?

Meta answer: because we still use a calendar that was designed to track Roman feast days.