A new product reduces aggravation of shifting Daylight Savings Time

[Joe Eykholt]

In article <6027 at fortune.UUCP>, stirling at fortune.UUCP (Patrick Stirling) writes:
> >The general problem is to
> >know at time X whether time Y is daylight or standard time.  Your
> >product doesn't do this unless X is equal to Y.
> >An example of the problem that your product cannot solve is: on June
> >15, I do an "ls -l" of a file created last April 15.  Do I display its
> >creation time in daylight or standard terms?
> >  -=- Andrew Klossner
> 
> It doesn't matter. Display the time in the file's stats data as is. Files
> will still be displayed in the right order. The only time you have to worry
> about the the hour before fall-back (1am to 2am one Sunday morning in October).
> Anyone at work then deserves to be confused! There  is already so much scope
> for duplicated and out of order times in inter-machine communications that
> one more instance won't matter.
> 
> patrick
> {ihnp4, hplabs, amdcad, ucbvax!dual}!fortune!stirling

It DOES matter.  The conversion isn't being done in the ls program, but
in a library function whose duty it is to convert from an arbitrary GMT
time to the correct local time.  That function even has code in it for
the special years of 1974 and 1975 when the U.S. DST period was different.

And "ls' doesn't get confused by someone working in the hour before
fallback because the system keeps the timestamps in GMT.  This is really
beautiful and simple and the only way to do things, because you can
display the time in whatever zone you are in, not just the local zone
of the guy that modified the file.

(One of my pet peaves about SCCS is that it keeps the time of the deltas
in the file in local time, and won't let you apply a delta to a file that
was modified at a later local time, because it figures the clock is set
wrong, even if the two local times are in different zones.  I discovered
this while playing around with the TZ variable.  But, I digress.)

Your product sounds great for letting systems know what time it is in UT
or GMT, which is just what we need, but I think the conversion rules from
GMT to local time and back should be done in software.

Now, if we could only get everyone to agree what the daylight savings time
rules are going to be.
-- 

				Joe Eykholt
				Amdahl Corporation
				1250 E. Arques Avenue,  M/S 316
				Sunnyvale, CA 94088-3470
				...{hplabs|ihnp4|seismo|decwrl}!amdahl!jre

[The opinions expressed are those of the author and not necessarily
those of Amdahl Corporation, its management, or employees.]