There should be a health warning. WARNING: The Date object will give you the screaming heebie-jeebies. It will have you banging your head against the wall begging for mercy.
Anyway, now that we've got that out of the way.
You'll notice that 1 - (1/24) = 0.9583333...
This means that we're an hour short of 1 day in your example.
Why? Because of daylight saving time on your computer.
When you do new Date(), or new Date(x,y,z), you get the date alright, but you also get daylight saving time thrown in for free, according to what your computer thinks the daylight saving time would have been for that date. (Possibly based on this year's settings: so if Daylight savings time changed 1 April this year in your locale, your computer will presume that it changed at the same date 18 years ago too, I think).
What you are NOT getting is UTC time for the supplied date.
So when you subtract two dates (without hours and minutes, the computer presumes I think midnight), the computer will convert each to the number of millisecond from 1 Jan 1970 based on daylight saving time for your locale at midnight on the date specified.
So you can see that you might easily get calculations that are an hour off.
I think that a safe way around this is to get the timezone offset and add that too. For instance, on my computer I get:
(Of course, the result is in minutes, so you have to calculate for that).
You will probably get different numbers.
The question is, how safe is this? If you create a database of times which will be read on a computer in a different part of the world, will the times be right?
It requires very careful thought. When you say "2013, 11, 18", what time do you actually mean?
Thx for this explanation!
I didn't consider time zone offset at all. So this is the end when we start to play with the time.