Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!ucbvax!ISUMVS.BITNET!GG.SPY From: GG.SPY@ISUMVS.BITNET ("John Hascall") Newsgroups: comp.os.vms Subject: Re: The ongoing DST debate: a stupid suggestion Message-ID: <8805261059.AA22151@ucbvax.Berkeley.EDU> Date: 24 May 88 21:41:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 92 > Date: Thu, 19 May 88 15:04:00 LCL > Sender: INFO-VAX Discussion > From: RALPH%UHHEPG.BITNET@CUNYVM.CUNY.EDU > Subject: The ongoing DST debate: a stupid suggestion > To: John Hascall > > From: Ralph Becker-Szendy RALPH AT UHHEPG > Subj: The ongoing DST debate: a stupid suggestion > From a recent message: >> Ittai Hershman's proposal suggests a simple solution to the problem faced >> by VMS users in Indiana, where DST is not used: just set DST_INVERVAL to >> zero. I like that. > > Or even easier, do it like most data acquisition machines used in astronomy: > run the clock in UT. That is "Universal Time", also known as Greenwich Mean > Time. You never have any problems with time-zones or daylight saving time. You > just have to educate your users that the clock is always going to be some hour s > off (here in Hawaii it's 10 hours). You can even synchronize your computer > clock to the nearest WWV transmitter, and the time on your computer will be > accurate to a microsecond. > [comments on surfing omitted] > > Ralph Becker-Szendy RALPH@UHHEPG.PHYS.HAWAII.EDU > University of Hawaii / High Energy Physics Group RALPH@UHHEPG.BITNET > Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822 (808)948-7391 At the risk of beating a dead horse.... This seems (to me) like the beginning of a good scheme. 1) run the system clock in UT and use these numbers for things that need a nice continuous function with no jumps (logs, accounting, etc). (Basically the system just uses a quadword value and doesn't really care what the time base is--only users care). 2) have SYSGEN parameters (the solution to all problems involves sysgen parameters, doesn't it? :-) as follows so users could see and use times in a convenient fashion: CLK_OFFSET number of 100ns intervals to add-to/subtract-from UT to get local standard time CLK_ALTADD number of 100ns intervals to add-to/subtract-from UT+CLK_OFFSET to get "alternate" local time CLK_OFFNAME string to identify local standard time (i.e., CST, PST, etc.) CLK_ALTNAME string to identify local alternate time (i.e., CDT, PDT, etc.) CLK_ALTON when to switch to alternate time (quadword value in UT) CLK_ALTOFF when to switch back to standard time (quadword UT) When ever a current time is requested in other than UT-base, the system could compare the current UT to CLK_ALTON or CLK_ALTOFF (depending on the current local-base) and see if it is time to change local-bases, if it is, it could add 1 year to CLK_ALTON or CLK_ALTOFF as appropriate to be ready for next year (subject to the whims of congress). 3) Add a parameter to $ASCTIM to indicate whether you what the time back in UT, Local-time, or Alternate-local-time (while we are at it why not add a flag for 24/am-pm time?). timtyp: bit 0 if on indicates am-pm rather than 24-hour time bit 1 if on indicates use currently active local-time bit 2 if on indicates use standard-local-time bit 3 if on indicates use alternate-local-time bit 4 if on indicates return the offset as well $ASCTIM(retstr,timadr,timtyp) could return something like (assumming May 24th is during daylight savings time): timtyp (low byte) returned time 0000 0000 (or omitted) 24-MAY-1988 10:06:59 UT 0000 0010 (or 0000 1000) 24-MAY-1988 16:06:59 CDT 0000 0011 (or 0000 1001) 24-MAY-1988 4:06:59 PM CDT 0001 0011 (or 0001 1001) 24-MAY-1988 16:06:59 CDT (+06:00) Similarly add a parameter to $BINTIM to indicate what format the input time string is in. This would seem to eliminate most problems (nothing like a sweeping generality to generate replies :-). John Hascall ISU Comp Center p.s. whatever happened to the fad of including a line at the beginning for the line-ea