
Why does subtracting these two times give a strange result? (2011) - gs7
http://stackoverflow.com/questions/6841333
======
geuis
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
You do realize that's completely impossible. Time is not absolute.

~~~
bladedtoys
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
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.

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

------
apaprocki
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
I get 20. Care to elaborate?

~~~
apaprocki
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
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
Another problem domain like this is color representation.

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

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

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

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

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

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

