time change

[jc at trillian.mit.edu (John Chambers)]

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