davids@well.UUCP (David Schachter) (09/08/86)
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. 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 Schachterark@alice.UucP (Andrew Koenig) (09/08/86)
> 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. This doesn't help. NBS broadcasts UTC, not local time.
andrew@hammer.UUCP (Andrew Klossner) (09/08/86)
[]
"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]stirling@fortune.UUCP (Patrick Stirling) (09/09/86)
>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
davids@well.UUCP (David Schachter) (09/10/86)
In article <6032@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >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@hammer.UUCP (Andrew Klossner) (09/11/86)
[]
"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. :-)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]jre@amdahl.UUCP (Joe Eykholt) (09/12/86)
In article <6027@fortune.UUCP>, stirling@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.]