std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/08/86)
Date: Tue, 7 Jan 86 16:56:17 est From: seismo!cbpavo.cbosgd.ATT.UUCP!mark@sally.UTEXAS.EDU (Mark Horton) Organization: AT&T Bell Laboratories, Columbus >What you want is a processor that steadily ticks along with >only slight corrections to the time while running to correct >clock drift. Exactly. This is what UNIX does now, and I am not suggesting any changes to this behavior. What V7 does is keep internal time as time_t in GMT, and next to it are a couple of flags representing offset from GMT and a daylight flag. These two flags don't affect the time(2) call, they are just passed to the ctime(3) routine when it asks the kernel for them with ftime(2). The local time is then calculated, taking these into account. >I claim that all programs that care about time should keep all >times internally in GMT (or UCT or whatever you want to call it), and >convert from/to local time on input/output. This is, in fact, the >only way they can not be upset when the time zone of the computer >suddenly changes (which in effect it does when daylight savings >comes and goes). What do you mean "keep all times internally"? If you're referring to such things as the L.sys UUCP database, I think it's obvious that this has to be in local time (not only because of the potential for human error otherwise, but because you'd have to change it by hand every time you go into or out of daylight time if it were in GMT.) If you're referring to local timestamps, then certimely a time_t (seconds since Midnight, Jan 1, 1970, GMT) is a good way to do this, if you don't have to represent dates before 1970, like birth dates. >My understanding of the centralized proposal is that this >would not longer be possible, that the computer itself would >change times when DST started and ended. Not at all. What changes is the way the time is displayed to users, displayed in log files, and interpreted when a user inputs a time. Clearly such uses should be in the local time zone. (Whether this means "local" for the machine or for the user is apparently an open issue.) I gather you are not suggesting that you have a need for a particular process (or user) to indicate he's in a different time zone from the system default, although apparently at least one other person has indicated that on MULTICS people do this. I wonder if anybody uses this ability on UNIX? >We have been mostly lucky because savings time changes in the US at >a time when there isn't much going on, and people don't >notice what happens to, say, at and cron when the clock >changes under them, because they don't do much at that >time of day. But with world-wide access to central computers on the >horizon, and in some applications (such as hospitals) this is >changing. If I were running a 24 hour critical application, such as a hospital, I would demand that all time logs be 100% correct. Since the real clock jumps forward or backward by an hour twice a year, the logs had better do this too (and include the time zone so you can tell if 2:30 AM was the first or second 2:30 that night.). UNIX already does this quite nicely (at least in the USA, until Congress decides to change the rules.) Mark [ A couple of readers have taken the moderator to task for posting the article to which Mark replies here, since it was clearly based on a misunderstanding both of what Mark proposed and what UNIX does. I posted it because I thought it would give Mark a good opportunity to clarify the points on which both that and a previous article showed confusion. I believe he does so ably here. However, I will probably be more strict in the future in winnowing such submissions as the one to which he is replying. I solicit further input on this as well as any other thoughts by readers on how moderation is done in this newsgroup. For instance: the V5N11 is in the Subject line because one notes reader wanted it there; yet another notes reader complains that it interferes with the subject kill capability of notes. Other opinions? -mod ] Volume-Number: Volume 5, Number 11