A new product reduces aggravation of shifting Daylight Savings Time
David Schachter
hassles caused to system managers by Congress's decision to change the start/
stop dates for Daylight Savings Time. My company's product can help.
In net.newprod, I'm putting a new product announcement for a clock that
receives a radio broadcast from the U.S. National Bureau of Standards, thus
it always has the correct time. If you don't get net.newprod, here's where
to get more info:
Precision Standard Time, Inc.
2585 Scott Blvd.
Santa Clara, CA 95050
or call (408) 980-8001 and ask for information on the Precision Clock/Time
Receiver, Model OEM-10(tm).
I am an employee of the firm.
-- David Schachter
Andrew Koenig
> hassles caused to system managers by Congress's decision to change the start/
> stop dates for Daylight Savings Time. My company's product can help.
> In net.newprod, I'm putting a new product announcement for a clock that
> receives a radio broadcast from the U.S. National Bureau of Standards, thus
> it always has the correct time.
This doesn't help. NBS broadcasts UTC, not local time.
Andrew Klossner
"In recent weeks, net.misc and net.unix-wizards have hosted a
discussion of the hassles caused to system managers by
Congress's decision to change the start/ stop dates for
Daylight Savings Time. My company's product can help. In
net.newprod, I'm putting a new product announcement for a clock
that receives a radio broadcast from the U.S. National Bureau
of Standards, thus it always has the correct time."
You didn't pay attention to the discussion. 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 (decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]
Patrick Stirling
>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
David Schachter
>This doesn't help. NBS broadcasts UTC, not local time.
My company's clock can output UTC (essentially Greenwich Mean Time or GMT),
local time, or local time with auto-DST correction. You tell the clock your
timezone by means of DIP switches or over the serial port. For applications
requiring more accuracy, you can also encode the distance from the NBS trans-
mitters for propagation delay compensation. The output can be in 12 hour or
24 hour time and always tells you if daylight savings time is in effect and
if auto-DST correction is enabled.
If there are more comments, it might be wiser to use e-mail or phone, rather
than cluttering the network. My phone number is (408) 980-8001, from noon
to nine pm, Pacific Time. (If I don't reply to e-mail, try the phone: I don't
know if I can receive Usenet mail on this system.)
Another person remarked the clock doesn't solve the entire problem. That is
correct. It solves part of the problem, telling you when DST starts and stops
and providing an accurate, unattended, NBS-tracable source of time.
It is 0122, Pacific Daylight Time, exactly. I'm going to bed.
Andrew Klossner
"I do an "ls -l" of a file created last April 15. Do I
display its creation time in daylight or standard
terms?"
"It doesn't matter. Display the time in the file's stats data
as is. Files will still be displayed in the right order."
On the contrary, it matters very much. If we ignore the daylight
correction factor, all files created during the warmer half of the year
will appear to be one hour older than they truly are. Even the one
that I made five minutes ago. This is quite unfriendly.
By the way, if we truly "display the time in the file's stats data as
is," we will be looking at a count of seconds since midnight GMT,
January 1, 1970. That's even less friendly. :-)
Joe Eykholt
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.]