Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site azure.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!teklds!copper!azure!stevesu From: stevesu@azure.UUCP (Steve Summit) Newsgroups: net.unix-wizards,net.lang.c Subject: Daylight Savings Time Message-ID: <507@azure.UUCP> Date: Fri, 6-Dec-85 22:15:55 EST Article-I.D.: azure.507 Posted: Fri Dec 6 22:15:55 1985 Date-Received: Sat, 7-Dec-85 21:13:23 EST Followup-To: net.unix-wizards Distribution: net Organization: Tektronix, Beaverton OR Lines: 70 Xref: watmath net.unix-wizards:15994 net.lang.c:7331 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.