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

http://stackoverflow.com/questions/6841333

by gs7 • 13 years ago

41 24 13 years ago

apaprocki3• 13 years ago

There's much more simpler (and relevant) ways to break date logic than going back to 1927. Take for instance:

  var d = new Date(2013, 9, 20);

For 200 million people in the world, d.getDate() will be 19.

Now, are you sure your app doesn't break when that happens?

bigfoot13442• 13 years ago

I get 20. Care to elaborate?

apaprocki3• 13 years ago

That date happens to be the date of DST transition in Brazil and Brazil is one of about 10 or so countries that transition at midnight rather than some later time such as 2am. Because of that, and due to how ES5's timezone logic works, the time winds up resetting backwards an hour, putting the Date object in the day before.

The other countries that do this are Chile, Paraguay, Cuba, Greenland, Iran, Lebanon, Syria, West Bank, and Gaza Strip. (I think I got them all..)

stygiansonic• 13 years ago

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".

ginko• 13 years ago

Another problem domain like this is color representation.

kbenson• 13 years ago

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).

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?

Why is your location important?

claudius• 13 years ago

Wouldn't DST have two different time zones? Over here it is CET/CEST, so if I were to store a date within that hour and its timezone, that would be as good as storing it in UTC, given that the timezone gives just the current offset from UTC.

apaprocki3• 13 years ago

Nit: You're referring to the UTC offset, which is not the same thing as a timezone. The offset lets you easily get back to UTC as you say, but only for the datetime in question. A (machine readable) timezone would be something like America/Los_Angeles and wouldn't disambiguate the timestamp. (You don't know whether it was pre- or post-transition without an offset.) The timezone does, however, let you always unambiguously convert UTC to a local datetime with offset. Abbreviations like CET/CEST aren't standardized -- just read the tz mailing list for all the recurring drama regarding the abbreviations in Australia.

MichaelGG• 13 years ago

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.

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.)

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.

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."

prezjordan• 13 years ago

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

bernardom• 13 years ago

Especially given that he answered it 16 minutes after it was asked. No way this was chance.

yen223• 13 years ago

It's a very common practice on StackOverflow to give a short answer first, then flesh out the rest with an edit later.

code_duck• 13 years ago

No, it's not chance – he asked on stack overflow because he knew the chances would be likely that someone would find the answer. Skeep is an extremely knowledgeable person and it shows in his history there, so I'm not surprised that he was able to come up with the answer.

ktran03• 13 years ago

Have a look at the comments, Skeet professed to knowing the solution beforehand. Still impressive nonetheless.

Kranar• 13 years ago

StackOverflow permits and even encourages people to ask questions and then answer their own questions.

All that matters is that the question/answer is of importance or interest to developers, not who asked or answered it.

jbri• 13 years ago

Honestly it seems fairly obvious to me - "clocks changed" is kind of the first assumption you make when two time strings that appear very close together parse as far apart.

After that, it only takes some quick googling to figure out what happened at the end of 1927 that could affect things.

Too• 13 years ago

Check John Skeets answer history :)

I think he's the #1 answerer on stackoverflow. He always answers extremely fast and correct. Sometimes i wonder if SO is his full time job. In any case, any senior developer who has worked a lot with time zones should have known where to look for the answer so it's not entirely unbelievable he could answer it so fast. The answer has also been edited, the first version, after 16mins, was just half as long.

bgdam• 13 years ago

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.

[0] http://www.timeninja.net

geuis2• 13 years ago

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?".

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.

Tloewald2• 13 years ago

You do realize that's completely impossible. Time is not absolute.

bladedtoys2• 13 years ago

If you chose a single non accelerating frame of reference outside of any gravitational fields. (a highly theoretically thing no doubt) you'd be ok. All other observers, those with a different relative velocity, will obviously disagree about simultaneous events etc. but they will have undergone acceleration at some point and so be non-definitional.

The problem is that time may not function correctly in the early universe, (say around plank time).

Another maybe more practical idea is to take the average temperature of the background radiation and peg time to the way it (or the average temperature of the universe ) cools down.

Or peg time to the Hubble flow. Since we now know the Hubble flow changes over time, you could peg a measurement of time to that.

Neither of these can give us datetime numbers for the very early universe but time may be screwed up then anyway: time maybe nonsense then.

bladedtoys2• 13 years ago

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

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

Related Stories