Why does subtracting these two times give a strange result? (2011) | Hacker News Reader

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

stackoverflow.com

41 pointsgs724 comments

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.

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

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.

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.

So, this theoretical perfect time measurement won't work on or near any planet or other massive body (where "near" is relative and as your technology improves it will get bigger and "massive" is relative and as your technology improves it will get smaller). It also won't work in any accelerating frame of reference, such as spin-gravity.

So, this is "possible" only in the sense that if constrained to be useless it would theoretically be possible, but not practical.

Awesome, let's get right on that :-)

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?

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.

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.

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?

I get 20. Care to elaborate?

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

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

Another problem domain like this is color representation.

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

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

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

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

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

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com