time change
John Chambers
jc at trillian.mit.edu
Fri Sep 20 16:53:10 EDT 2002
| Seth Gordon <seth at genome.wi.mit.edu> writes:
| > Nathan Meyers wrote:
| > > On Fri, Sep 20, 2002 at 03:01:02PM -0400, Rob Ransbottom wrote:
| > > > For no compelling reason I've always wanted to set my clocks to
| > > > UTC.
|
| There is a good reason they invented UTC in the first place - you
| always know when an event occurred relative to some other event,
| e.g. 8 am EST is after, not before 10 am CET. Consequently, when your
| files move from one timezone to another (because you took your laptop
| to Europe or because you emailed a file to the other coast) you still
| know which file is older.
Something I've found fun to bring up when the topic is java is to
mention that every year, when DST goes into effect, the online java
discussions invariably have a rash of panicky questions from people
whose timestamps are suddenly off by varying number of hours.
Invariably it turns out to be time-zone problems caused by the fact
that the java libraries use local time internally, and the code just
can't figure out how to adjust for DST for timestamps coming from
other machines. After a decade or so, they still don't seem to have
gotten the bugs out (though there are rumors of some distributions
that work among their own type).
When I first ran across the local-time in the java specs, a big red
flag popped up in my brain, along with the thought "They'll never
make it work right". I'd already done enough network time work to
understand what this means. I've shot down several java proposals by
pointing out that for legal reasons, they need their timestamps to be
correct, and a quick search for java time-zone discussions will
persuade them that it's not possible yet.
Java does have the additional problem that it is a networked language
where code is downloaded to clients' machines. So fixing the time
routines in your own library doesn't help much. Until they can get
this working in all releases (including Microsoft's), you can't rely
on java's timestamps anywhere.
In a network situation, UTC is the only time zone that works. If you
use anything else internally, you're going to have a lifetime of
trying to get the bugs out.
It's interesting that the guys at Bell Labs understood this back in
the early 70's, and decreed that Unix's internal time would always be
GMT everywhere. But they had probably seen enough grief within the
phone system from the use of local time.
| > > > Can the various Window OS deal with this?
| > > No.
I've seen some corporate types (religious IBM/MS types) going through
great deals of pain to try to patch up the problems with files
generated in multiple time zones. They won't admit, of course, that
using local time is the entire reason for their problems. They *know*
that their local time zone is the correct one, and if everyone else
could be persuaded to use it, there wouldn't be a problem. And they
never seem to understand that this is, in fact the solution to their
problem, since they can't agree on which local time zone is the one
they want to use.
I've also seen this attitude in unix circles. But they can usually be
persuaded.
More information about the Discuss
mailing list