cottrell@nbs-vms.arpa (COTTRELL, JAMES) (11/27/85)
/* > >> I think the concept of DST is stupid, but so long as > >> it has to be dealt with, some means must be provided. Who says you have to deal with it? The Mythical Man Month chides IBM's 360 OS (whatever it's called) with wasting 300 bytes (or so) of resident kernel space worrying about various date changes (end of year, leap year, or DST or some such) when this would be (so they say) better handled by the operator once (or twice) a year manually. UNIX will never pass a Turing test with such sophisticated algorithms! What most people do is wonder around until they notice they need to set their watch correctly. Of course there is the bootstrapping problem, *somebody* has to set their watch first! Probably TPC. Hey, maybe that's where the algorithms came from. Besides, where is the interest on all that borrowed time? Talk about the National Debt, how much does the government owe us on that one. > >Perhaps, perhaps, but it'd be better to leave that up to the application > >instead of stuffing the library or forcing some PC user to create a file > >at certain times of the year just to run some program that happens to be > >written in 'C'. ... It wouldn't have to. It would just check for the file, see that it was not there, and pretend it wasn't DST. The worst that would happen is that you would be (consistently) an hour off. Then there would be a war between the C programmers & the Fortran programmers about setting back/ahead the clock because the time was wrong. Besides, you don't have to use the library routine. > Watch out people! The latest proposal in Congress to keep elections from > being decided before the West Coast gets its chance to vote involves a bad > change to Daylight Savings Time! > > As I read it in the Post yesterday, the proposal is to make the polling > places close at 7:00 EST, 8:00 CST, and extend Daylight Savings Time for the > West Coast two more weeks till election day! Don't you have it backwards? 8pm CST is 9pm EST. > The idea of changing the DST algorithm for a) West Coast sites only, and > b) only in an election year doesn't really turn me on AT ALL... Me neither. Look at the NFL. It's games are broadcast in real time. Aren't national elexions more important? Why not just keep the polls open till midnite here & nine out west? We never get the vote counted before morning anyway. > I think this > is a powerful argument for hiding the kluges in either a library routine or > the system. Somewhere it can be setup when the system is configured, and not > have to be replicated in hundreds of programs. If it is in the system, one > would not have to rebuild programs sent from elsewhere, while if it is in the > library one would at least have to re-link-edit. Or just ignore it. You see, no one has a seasonal hemishpere date. Can you imagine NHD (Northern Hemisphere Date) & SHD being exactly six months apart? If the Aussies & Latins can have Xmas in the summer, why not just have ONE time zone! This is the only way I'll ever get to work by 9 in the morning. > Let's keep our eyes on this particular snake - it just might bite us all > someday... More snake oil? > Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA jim cottrell@nbs */ ------
golde@uw-beaver (Helmut Golde) (12/02/85)
I am unclear as to why *any* application program would ever want to know whether daylight savings time is in effect or not. As long as the localtime() function returns the current local time, why care whether DST is in effect at all? I understand that the operating system might need to know if its real time clock is calibrated in GMT, but user programs shouldn't need to know this information. In any case, the most prudent route would be to have the DST flag have THREE possible values: 0 currently on standard time 1 currently on daylight time -1 daylight status unknown -- Peter Golde
seifert@hammer.UUCP (Snoopy) (12/03/85)
In article <1727@uw-beaver> golde@uw-beaver.UUCP (Helmut golde) writes: > I am unclear as to why *any* application program would ever want to know > whether daylight savings time is in effect or not. Example: date(1) needs to know. Typical output from date: Mon Dec 2 14:30:03 PST 1985 ^^^ Date needs to know if it is dst or not for printing out the date, and also for setting the date, since it has to convert the time given by root from local time to GMT before calling settimeofday(2). I have received two replys so far to my survey. One said that he prefers to use GMT for everything. Fine, use "date -u". (there doesn't seem to be a option for ls -l to report in GMT. (no, ls -lu is somthing different)) The other seemed to think that allowing users to have their own timezone would mess up timestamps on files. Not true. Timestamps on files are stored as number of seconds since 1/1/70 GMT, and the local timezone (system or user) has nothing to do with it. The only thing affected is what the user sees when s/he runs date. As far as what to do about the bozo congresscritters changing the rules constantly, a solution would be to add a "manual" type of daylight savings time, which would look for the presence of a file to detirmine if it is dst or std. Snoopy tektronix!tekecs!doghouse.TEK!snoopy
barmar@mit-eddie.UUCP (Barry Margolin) (12/06/85)
In article <1679@hammer.UUCP> seifert@hammer.UUCP (Snoopy) writes: >In article <1727@uw-beaver> golde@uw-beaver.UUCP (Helmut golde) writes: > >> I am unclear as to why *any* application program would ever want to know >> whether daylight savings time is in effect or not. > >Example: date(1) needs to know. Typical output from date: > >Mon Dec 2 14:30:03 PST 1985 > ^^^ > >Date needs to know if it is dst or not for printing out the date, >and also for setting the date, since it has to convert the >time given by root from local time to GMT before calling >settimeofday(2). All that is required in order to do this is the name of the current time zone and the difference between it and GMT. The system doesn't need to know the special relationship between PST and PDT; as far as it need be concerned these are just arbitrary names for GMT-8hours and GMT-7hours (or maybe it is vice-versa). The above comments are based on a Unix bias. On Multics, the date/time conversion software includes a table listing many of the world's time zone names (in several languages, no less), along with the corresponding difference from GMT. The site can specify any of the zones as the system default, and a user can choose any as his default for the login session. When entering times, one may specify a time zone explicitly, and when printing out times one can ask that it be printed out in any recognized time zone. No special understanding of Daylight Savings Time exists -- the system administrators merely change the default time zone twice a year (if necessary -- our primary exposure system is in Arizona, which doesn't use DST). Many of our customers are outside the US, so hardcoding our DST rules would have been a nightmare. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
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.peterc@ecr1.UUCP (Peter Curran) (12/07/85)
Much of the discussion of Daylight Savings Time have underestimate the complexity of the problem. For example, in some places (e.g. western Europe), they use "double daylight savings time." The clock is advanced one hour in the early spring, then another hour in the early summer, then back an hour in the early fall, and another hour in the late fall. There are also some industries that stay on standard time when the world around them changes, and all sorts of other tricks. Man can create more complexity than you have yet dreamed of. -- Peter Curran Emerald City Research, Ltd. ...utzoo!ecrhub!ecr1!peterc
jsdy@hadron.UUCP (Joseph S. D. Yao) (12/18/85)
In article <641@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes: >On Multics, the date/time conversion software includes a table listing >many of the world's time zone names (in several languages, no less), >along with the corresponding difference from GMT. ... Nice, but nothing special and not unique to Multics. I had this working on an old PWB 1.0 system quite a few years ago. > -- the system administrators merely change >the default time zone twice a year (if necessary -- our primary exposure >system is in Arizona, which doesn't use DST). Many of our customers are >outside the US, so hardcoding our DST rules would have been a nightmare. Many systems don't have system administrators (at least not ones who are like you and me and know how to wreak magic), and so it is nice if they automagically put in the correct times. If there is a computable algorithm, it can be expressed on the computer in some simple form, even if only via numerical methods. joe -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
barmar@mit-eddie.UUCP (Barry Margolin) (12/20/85)
In article <126@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >In article <641@mit-eddie.UUCP> barmar@mit-eddie.UUCP (Barry Margolin) writes: >>On Multics, the date/time conversion software includes a table listing >>many of the world's time zone names (in several languages, no less), >>along with the corresponding difference from GMT. ... > >Nice, but nothing special and not unique to Multics. I had this >working on an old PWB 1.0 system quite a few years ago. Good for you. However, most of the participants here don't seem to be so lucky. >> -- the system administrators merely change >>the default time zone twice a year (if necessary -- our primary exposure >>system is in Arizona, which doesn't use DST). Many of our customers are >>outside the US, so hardcoding our DST rules would have been a nightmare. > >Many systems don't have system administrators (at least not ones who >are like you and me and know how to wreak magic), and so it is nice >if they automagically put in the correct times. Most systems have someone who turns it on. It doesn't take much more smarts to tell the system what time zone it is in twice a year. Many digital clocks make it harder than it would be on the computer: run a single set_system_time_zone command as root. >If there is a >computable algorithm, it can be expressed on the computer in some >simple form, even if only via numerical methods. But the problem is that it cannot always be expressed in any algorithm. On Unix it currently is expressed in an algorithm, and that is going to screw people if Congress changes the rules. Hardcoding any DST algorithm is like coding in rreagan (password "whitehouse") into login.c. It is guaranteed to be wrong in a few years and in other countries. I have heard that in some countries the switchover dates are specified yearly. With a command like the above, you get nice generality. If a particular system happens to be in an area with a regular pattern to the switchover then the command can be put into crontab, so the sysadmin doesn't have to do anything. Of course, if Congress legislates a new set of dates, only the crontab entries have to be changed. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
peterc@ecr1.UUCP (Peter Curran) (12/30/85)
Several people have suggested that the daylight savings problem can be resolved by providing some scheme (manual or automatic) for specifying the time zone when the system is booted. This isn't sufficient for many purposes. It is often necessary to display passed or future times reasonably (e.g. modification dates of files). Some method of specifying the transition dates for all years (and modifying it as the rules change) is necessary in any general purpose scheme of this sort. -- Peter Curran Emerald City Research, Ltd. ...utzoo!ecrhub!ecr1!peterc