5 ms·

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

41 points by gs7 13y ago

apaprocki 13y 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 13y ago
  I get 20. Care to elaborate?
  - apaprocki 13y 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 13y 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 13y ago
  Another problem domain like this is color representation.
kbenson 13y 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 13y 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.
  - apaprocki 13y 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 13y 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 13y 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 13y ago
  Especially given that he answered it 16 minutes after it was asked. No way this was chance.
  - yen223 13y 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 13y 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 13y ago
    Have a look at the comments, Skeet professed to knowing the solution beforehand. Still impressive nonetheless.
- Kranar 13y 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 13y 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.
bgdam 13y 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 http://www.timeninja.net
geuis 13y 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.
- Tloewald 13y ago
  You do realize that's completely impossible. Time is not absolute.
  - bladedtoys 13y 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.
    - geuis 13y ago
      I like the idea of tying it to the CMB value. Determine the rate of change, factor in the observed rate of universe expansion, etc. The real problem is that we need a point of reference that is external to our own frame of reference. Luckily, we have one. Light. Light moves at the same speed no matter what your frame of reference is. It's theorized that the early universe was dark for a very long time because any emitted photons were absorbed by other matter, because things were so dense. After a while, matter got ionized and expansion kicked in and the universe cleared up. This was the time of the first stars. So, we need realllly good telescopes. Fortunately they're being built. The idea is that you have to find the light from the first stars. Measure the redshift and find some type 1a supernovas from the period to give you distance. (Standard candles.) Then you have a base measurement of time. One problem is the redshift. There was a recent paper talking about how the earliest galaxies are so redshifted by now that their light is getting lost in the CMB.
bladedtoys 13y ago
Meta answer: because we still use a calendar that was designed to track Roman feast days.

41 points by gs7 13y 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 13y ago
I get 20. Care to elaborate?
- apaprocki 13y 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 13y 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 13y ago
Another problem domain like this is color representation.

kbenson 13y 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 13y 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.
- apaprocki 13y 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 13y 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 13y 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 13y ago
Especially given that he answered it 16 minutes after it was asked. No way this was chance.
- yen223 13y 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 13y 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 13y ago
  Have a look at the comments, Skeet professed to knowing the solution beforehand. Still impressive nonetheless.
Kranar 13y 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 13y 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.

bgdam 13y 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 http://www.timeninja.net

geuis 13y 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.

Tloewald 13y ago
You do realize that's completely impossible. Time is not absolute.
- bladedtoys 13y 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.
  - geuis 13y ago
    I like the idea of tying it to the CMB value. Determine the rate of change, factor in the observed rate of universe expansion, etc. The real problem is that we need a point of reference that is external to our own frame of reference. Luckily, we have one. Light. Light moves at the same speed no matter what your frame of reference is. It's theorized that the early universe was dark for a very long time because any emitted photons were absorbed by other matter, because things were so dense. After a while, matter got ionized and expansion kicked in and the universe cleared up. This was the time of the first stars. So, we need realllly good telescopes. Fortunately they're being built. The idea is that you have to find the light from the first stars. Measure the redshift and find some type 1a supernovas from the period to give you distance. (Standard candles.) Then you have a base measurement of time. One problem is the redshift. There was a recent paper talking about how the earliest galaxies are so redshifted by now that their light is getting lost in the CMB.

bladedtoys 13y ago

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