std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/07/86)
From: seismo!allegra!druil!khw@sally.UTEXAS.EDU Date: Mon, 6 Jan 86 17:55:22 EST I strongly oppose using a centralized time zone for each computer. It is unnecessarily constricting, creates problems with networking computers together and with daylight savings, and is not necessary. The major reason I read in Mark Horton's article for not using decentralized time zones is that security holes exist with system programs getting fooled about what time it really is. The reason they are getting fooled is not because of the decentralized nature of the time zone setting, but because they don't keep their internal times in some standard time zone. 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). We are running System III. We have a calendar application. Users were upset when the meetings they had scheduled for 8 am, (with the onset of DST) appeared for 9 am. The problem was the application was keeping stuff in local time, and not being very smart about it. A simple revision to use GMT instead fixed this problem, with the application not knowing or caring if DST is in effect or not. 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. Programs are like people; they get jet-lag when crossing time zones too fast, and for a program one time zone is too fast, unless a lot of care has been taken in writing it. What you want is a processor that steadily ticks along with only slight corrections to the time while running to correct clock drift. Changing states to kill off running processes, changing the time, and restarting may be acceptable in most environments that Unix has run in currently, but we should not restrict it to these environments. I want to be able to sell Unix to hospitals, for example. 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. Networks will shortly progress to the state where a common time shared by all elements is very desirable, and this might as well be the current world standard GMT. Such a common time is the only way to prevent ambiguities, and changing centralized times to compensate for DST will introduce these ambiguities. The problem with System III (besides rc not setting a default TZ that is passed on) is 1) the daylight algorithm is centralized. You really want an algorithm on a per process-group basis, that allows people from multiple countries that have different daylight savings definitions to call up and get the one suitable for them. 2) The syntax for the timezone allows only multiples of hours. Otherwise the problems come from system programs which use local time, not GMT. If the system programs were changed to use GMT, then cat'ing their files out would not show the time in terms that the System Administrator was used to (unless s/he is located in GMT). A filter could be used to translate these, or the SA could get used to reading GMT. With lengthy networks, the SA should be reading in GMT anyway to keep from getting confused when troubleshooting problems with another element on the network that isn't in the same zone. I claim that switching to a single centralized timezone is short-sighted. It may work for most applications we have now, but it is not the way to go for the future. Karl Williamson ATT ISL Denver ihnp4!druil!khw 303-538-4583 Volume-Number: Volume 5, Number 9