stevesu@azure.UUCP (Steve Summit) (12/07/85)
I hope nobody minds this on net.lang.c, but it was prompted by
several discussions there.
Somebody ought to do something more general about Unix time
conversion soon, precisely because of the fact that political
discussions are likely to continue to alter the algorithm. The
state of Oregon has already decreed that Daylight Savings time is
to start two weeks earlier and end two weeks later next year. I
don't know what Unix sites in Oregon are planning to do.
Although ctime has gotten pretty clever lately, under the
auspices of our friends at Berkeley, it will never be able to
predict the future. It's folly to have to recompile every
program that uses ctime every time the DST algorithm changes.
Howard Johnson at Cyb Systems has already mentioned what I've
been meaning to propose, namely that "This is yet another
application crying out for some kind of dynamic link editor."
In fact, in this case, it doesn't even have to be that difficult.
As the current 4.2 documentation for ctime points out,
"The program knows about various peculiarities in time
conversion over the past 10-20 years; if necessary, this
understanding can be extended."
The 4.2 implementation of ctime (actually localtime) is driven by
a single C data structure describing what the "peculiarities" of
the conversion were for various years. Dynamically linking in a
single data object like this is quite easy: nroff has been loading
the terminal driving tables that way for years. In fact, since
the information is tabular and not algorithmic, it would be
possible to store the information in a human-readable text file.
However, a compiled form would probably be preferable in order to
silence the inevitable complaints from those who will maintain
that reading and parsing a file off of disk is too time-consuming
every time ctime (actually, localtime) is called.
It's too bad that 4.3 will be out so soon -- there probably isn't
time to get this in.
Steve Summit
textronix!copper!stevesu
P.S. for people who don't understand what the problem is:
Unix keeps Greenwich Mean Time, and it is up to a program,
running in user mode, to convert GMT to local time, by adding and
subtracting the correct timezone and daylight savings time
corrections. This conversion is usually done using the routines
described under ctime in chapter 3 of the Unix Programmer's
Manual. These routines take the Greenwich Mean Time, adjust it
by the time zone, and figure out what time of year it is. If
it's a time of year that DST applies in, and if DST applies at
all, an additional hour is added. (Or is it subtracted? -- I can
never remember.)
What timezone to use, and whether DST applies at all where the
machine is installed, is determined using the ftime() system call
(gettimeofday on 4.2bsd). The timezone and DST flags are
compiled into the kernel (or hopefully user-settable on newer,
binary distribution systems).
Contrary to some implications made in some previous
articles on this subject, it is not necessary to make some
adjustment every six months to tell the system, "now start doing
daylight savings time -- now don't." The decision is always
based on the global flags, and on the time being converted (_n_o_t
the current time). For instance, if I do an ls -l on a file I
modified last summer, the modification time shown should be
reported the same even though DST doesn't apply right now.rees@apollo.uucp (Jim Rees) (12/09/85)
This does seem to me like a perfect example of why dynamic linking is good. My unix system has dynamically linked global libraries, and when I install a new release of the system, I get all the latest C library code without having to recompile or relink. It also makes the binaries smaller. Compare my /bin/date with one on another 68000 based unix system, but without global libraries. I bet you didn't know the date command carried around so much baggage. % ls -l /bin/date /yuban/bin/date -rwxr-xr-x 1 root 5926 May 9 1985 /bin/date -rwxr-xr-x 1 root 22528 May 13 1985 /yuban/bin/date
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/10/85)
It's 02:10 one Sunday morning. You have just made a very important update to a disk file. You clobber your file a few days later, so you restore it from a backup, which was run automatically at 02:30 Sunday. Funny, this doesn't look like the right file... "It's 02:30 -- Do you know where your files are?" I am 100% serious when I suggest that UNIX time reporting be done in UT rather than local political time. This is a technically correct solution to a difficult people problem. I have known people who operated on UT; when I was an SWL I did so myself. Why let yourself be sloshed around by politicians when you can establish a regular schedule with well-defined characteristics? The problems with the mapping UT <-> local_time are: (a) It is complex. (b) It is irregular. (c) It is unpredictable for the future. (d) It is poorly documented. (e) It is discontinuous. (f) It is multiple-valued. I say, who needs it?
warren@tikal.UUCP (Warren Seltzer) (12/11/85)
As it happens, the project I'm working on involves a network of Unix
and non-Unix systems both running C code. The central Unix system is
the time server, and sends time-set messages out over a network.
It also happens that the network elements need to know about Daylight
Savings Time changes *BEFORE* and *AFTER* they occur. That is, the time
set message is "It is now such-and-such, and we switch time in 3
hours and 2 seconds, and the switch is for +60 minutes". Or, "... we
switched 5 hours ago and the switch was for +60 minutes", which in our
case turns out to be the important situation.
This sort of thing is necessary if you have a network that passes around
time-stamped records that are supposed to be user-compatible and viewable
at different spots in the net.
Although we cannot of course expect C standards to pre-implement our every
application need, we can note that networks are very common these days, and
we found Unix time routines to be very helpful.
When central time servers set the time for peripheral nodes that are in
different time zones, similar requirements pop up.
teltone!warren
--
______
Warren Seltzer
Teltone Corporation
Kirkland, WA
206-827-9626
....uw-beaver!teltone!warrendave@rocksvax.FUN (Dave Sewhuk) (12/14/85)
/* rocksvax:net.unix-wizards / warren@tikal.UUCP (Warren Seltzer) / 10:46 pm Dec 10, 1985 */ >This sort of thing is necessary if you have a network that passes around >time-stamped records that are supposed to be user-compatible and viewable >at different spots in the net. Why bother with time zones. Make everyone talk UTC, where there is no DST. Time zones are an artifact of the routines that finally print out the time. That is how Unix does it in general. Here at Xerox all our time servers know their local time zone and pass only UTC times around. Our networks go all over the planet and few machines get confused over what time something happened. Dave arpa: Sewhuk.HENR@Xerox.ARPA uucp: {ihnp4,rochester,amd,sunybcs}!rocksvax!dave ns: "Sewhuk:HENR801C:Xerox".ns@Xerox.ARPA
drg@rlvd.UUCP (Duncan Gibson) (12/17/85)
Last year I did some work with the "Newcastle Connection" between two machines connected by a Cambridge Ring LAN. Both were V7 systems, but one was based on the standard Bell sources, and the other from an EUUG distribution for small machines (it was for an 11/23). One system took "British Summer Time" (BST) into account, and the other ran GMT. I can remember being incredibly confused when I copied a file from one machine to the other and did an 'ls -l' on it only to find that it wasn't due for creation for another hour (:-)) -- UUCP: ..!ukc!rlvd![rlvc!]drg ARPA: drg%rl.vc@ucl.cs JANET: drg@rl.vc
gdmr@cstvax.UUCP (George D M Ross) (12/20/85)
In article <985@rlvd.UUCP> drg@rlvd.UUCP (Duncan Gibson) writes: >Last year I did some work with the "Newcastle Connection" ... > One system took >"British Summer Time" (BST) into account, and the other ran GMT. I can >remember being incredibly confused when I copied a file from one machine >to the other and did an 'ls -l' on it only to find that it wasn't due for >creation for another hour (:-)) This is, surely, a failing in the way information is presented to the user. The poor user shouldn't be expected to remember all the quirks of the file servers (s)he might use -- rather the clients should hide them. In this case the date should have been converted into the appropriate local form before you, the user, got to see it. Perhaps this is a "feature" of the Newcastle Connection, or perhaps it's just ctime that's broken. -- George D M Ross, Dept. of Computer Science, Univ. of Edinburgh Phone: +44 31-667 1081 x2730 UUCP: <UK>!ukc!cstvax!gdmr JANET: gdmr@UK.AC.ed.cstvax
drg@rlvd.UUCP (Duncan Gibson) (01/07/86)
[from my original...] Last year I did some work with the "Newcastle Connection" ... ... One system took "British Summer Time" (BST) into account, and the other ran GMT. I can remember being incredibly confused when I copied a file from one machine to the other and did an 'ls -l' on it only to find that it wasn't due for creation for another hour (:-)) [from George D M Ross' reply...] ... Perhaps this is a "feature" of the Newcastle Connection, or perhaps it's just ctime that's broken. [and a quick followup by me...] It has been pointed out that (thanks Robert) that as Unix internals are in GMT as long as the two machines are running synchronised GMT then this is not a problem. That is the point: when I set the date I used *my* local time, ie I typed in the time as given by the trusty wrist watch, without bothering to convert to GMT, so the two machines were not running synchronised GMT. There was a smiley on my original, but to stop the flames... The Newcastle Connection certainly provides the user with a distributed environment, and it's pretty amazing to use a multi-machine Un*x system. Like a single machine Un*x system, there is no escaping an idiot user, so if the administrator can't read his watch, what else do you expect :-) -- UUCP: ..!mcvax!ukc!rlvd!drg JANET: drg@uk.ac.rl.vc ARPA: drg%rl.vc@ucl.cs.arpa