JRS: In article <opsdh37io1x13kvk@atlantis>, dated Sun, 29 Aug 2004
16:01:43, seen in Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
It would be safer to use numbers, rather than a string as there is no
exact definition for string date formats. I'm certain that the format
above will cause problems in some browsers.
Can anyone provide an actual example of failure? ISTM worth settling
the point of whether all javascript systems, however configured, can
read a date with English-MON DD YYYY in arbitrary order and
reasonable punctuation.
var birth = new Date(2003, 7, 10, 7, 7);
Not fully equivalent, though; the first returns a time_t (ms) and the
second a Date Object.
That form uses Month-1, and hence is amenable to human error; I'd
suggest new Date("2003/08/10 07:07") , in which the string looks like
the right date and is as near ISO-8601 as my system accepts. Again, can
anyone find an example of failure of that form?
[snip]
Calculating differences in dates is simply a matter of subtracting one
Date object from another.
No. It does give the absolute time interval.
This will yield a number representing the
milliseconds.
Yes.
You can then use a new Date object to return the number of
years, months, days and hours:
No; *a* number of ...
Consider a boy born 2004-01-01 00:00:00; at 2008-12-31 12:00:00 he will
be nearly 5 years old, and looking forward to his party on the next day.
He will be 1461 + 365.5 days old.
Consider a boy born 1970-01-01 00:00:00; he will be 1461 + 365.5 days
old on 1975-01-01 12:00:00 he will be 5 years old, and looking forward
to his party on that afternoon.
A boy born 2004-02-01 will be a month old on 2004-03-01 ; 29 days.
A boy born 2005-02-01 will be a month old on 2005-03-01 ; 28 days.
Starting from 1970-01-01, 29/28 days is not yet a month.
The lad was 6 months old on 2004-02-10;
starttime = Date.parse("Aug 10,2003, 07:07")
finaltime = Date.parse("Feb 10,2004, 07:07")
D = new Date(finaltime-starttime)
gives me Sat Jul 4 02:00:00 UTC+0100 1970 -> 6 mo 3 dy 2 hr; the
same every year, since the end of Feb real time is not crossed.
Now consider those, of all ages, who were born on March 28th at noon.
They will have been a week old on the following April 4th, at noon. But
in Europe[~] 3/7 of them will then have been an hour younger than the
other 4/7; and probably /vice versa/ in much of the USA.
[~] EU & neighbours; but not Iceland (there may be other exceptions).
Moreover, the lad may be a foreigner. Differences from GMT will be
(too) properly allowed for in determining the interval; but datum is
1970.0 GMT. Your method, which adds diff to datum and then uses the
getFullYear family, gives a result depending on the location of the
answering system. Few places use GMT as civil time year-round.
t += ' year';
if(1 != years) {t += 's';}
t += ', ' + months + ' month';
if(1 == months) {t += 's';}
t += ', ' + days + ' day';
if(1 == days) {t += 's';}
t += ', and ' + hours + ' hour';
if(1 == hours) {t += 's';}
alert(t);
Erroneous pluralisation?
IMHO, the OP needs to step forwards in integer civil years from the DoB
until the next step will pass the present instant, counting them; then
likewise in months, days, hours, and minutes.
He could step backwards; I expect that the answer will sometimes[*]
differ.
[*] Assuming that the OP repeats the test for a statistically-
significant[+] number of sons[#].
[+] Which need not be all his own.
[#] Or daughters, wives, etc.
A further correction, probably of about 9 months, will be needed if the
lad is Korean (4.5 mo if half-Korean?), and the stated date is DoB.
See via below.
