JRS: In article <Se************ ********@comcas t.com>, dated Mon, 1 Aug
2005 01:26:29, seen in news:comp.lang. javascript, Randy Webb
<Hi************ @aol.com> posted :
Dr John Stockton said the following on 7/31/2005 10:36 AM:
It looks as if the USA may be changing its Summer Time (DST) Rules,
perhaps with immediate effect.
It's possible, depending on what Congress decides to do with the law.
AIUI, Congress has decided; but that is not sufficient, and it may have
to re-decide.
Browsers use the rules selected in the OS, and I predict that in many
cases the rules will not have been updated.
That depends on the OS and how updated it is.
Manifestly.
Since time servers send GMT/UTC, the actual civil time of the computer
may be wrong; or, if the user corrects it manually the results of UTC
functions may be wrong.
And how is that different than any potential problem now?
Because now in the US the overwhelming majority of systems, having been
delivered after 1987, were delivered with the current US rules set. If
the US rules change, and AIUI the plan is to start the new dates in
2007, then it's reasonable to expect that a significant proportion of
machines will not be updated during Winter Time 2006/7.
At present, where time on a computer matters, it can be set by a UTC
server and checked with a wall-clock; therefore, errors are likely to be
small. When the actual rules are changed from the stored rules, there
will be a stubborn one-hour discrepancy.
The user, however, will be able to see that the civil time shown
on/after (maybe) 2007-03-11 differs by an hour from that which his radio
& TV provide. He may use the command-line TIME command, or the Windows
equivalent; or he may cunningly shift his location by a zone; or he may
even update his DST data.
Scripts running in general locations and showing the US date/time will
need changing, or at least will need new parameters.
Again, how is that any different than any possible problems now? If the
computers clock is wrong, it's wrong and the programmer can't possibly
determine why it's wrong so it can't be compensated for.
That's "Scripts running in general locations and showing the US
date/time" - general does not include the US. The computers will
probably be showing their own local time accurately enough, and will
know the relation between that and GMT. But they will need updating to
know that (say) Chicago's offset now changes in March.
Many businesses want to know remote civil time.
I shall need to update some of my material, and have begun to prepare
for it.
And I know of one news server in the USA that for years was mis-operated
in respect of DST, behaving as if its GMT was being changed rather than
its offset.
Then that was a result of the server being improperly configured, not a
DST problem.
It shows that even those in charge of the news server at or of a US
software manufacturer can misunderstand how to deal with clock changes.
US /hoi polloi/, then, are at least as likely to fail to deal correctly
with changes in clock changes.
ISTM worth considering and preparing for the possible errors that may
appear on and after Sunday 2005 October 30.
Sources led me to believe that the change was intended to occur
immediately; others now make me think it more likely that the change
will start in Spring 2007. AFAIK, it's not settled.
The US seems to rely on knowing "Spring forward; Fall back". Now
definitions of Spring and Autumn vary - the current change dates are by
at least most definitions in Spring and Fall, but the new dates may not
be.
--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demo n.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
