RALPH@UHHEPG.BITNET (05/20/88)
Date: 19-MAY-1988 14:56:16.39 From: Ralph Becker-Szendy RALPH AT UHHEPG To: 0::"info-vax@kl.sri.com",RALPH 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 hours 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. Or you emigrate to Hawaii (like I did). First of all, we don't have daylight saving time; there is enough sunshine to make saving it ridiculous. Second, there are only two different times known in Hawaii: Surf's Up, and Surf's not up. By the way, this posting is NOT meant serious, if you haven't figured that out yet. Just coincidentally, I don't surf. I work on the VAX in my office in an ugly concrete building all the time. 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
GG.SPY@ISUMVS.BITNET ("John Hascall") (05/25/88)
> Date: Thu, 19 May 88 15:04:00 LCL > Sender: INFO-VAX Discussion <INFO-VAX@UBVM> > From: RALPH%UHHEPG.BITNET@CUNYVM.CUNY.EDU > Subject: The ongoing DST debate: a stupid suggestion > To: John Hascall <GA.JPH@ISUMVS> > > 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
IMHW400@INDYVAX.BITNET (06/01/88)
Ralph Becker-Szendy (RALPH@UHHEPG) (facetiously) suggests setting the system
time to UT regardless of the local time zone, and John Hascall (GA.JPH@ISUVMS)
responds with a serious proposal to:
o keep the clock in UT regardless of time zone;
o add SYSGEN parameters to specify the standard and DST offsets from
UT to local time, and the dates between which DST applies;
o mods to system services, which allow us to control the type of
conversion applied to binary times.
I approve. This sort of thing has worked well in TOPS-20 for some time.
However, as stated Mr. Hascall's proposal fails to deal with the problem
of DST in the *past*. (TOPS-20 also fails to deal with this.) In other
words, if I want to convert a date-time from *last* year, when the DST Sundays
were different (not just different dates, but different "n'th" Sundays),
should we use this year's dates, or remember last year's? An ugly problem,
but manageable if we keep a table of (DST-on-Sunday-n,DST-off-Sunday-n,year).
(I didn't invent this method; it was proposed on the TOPS-20 wizards'
newsgroup.) The algorithm to determine the n'th Sunday in a given year
is not too difficult.
Is it worth dragging around an ever-lengthening table, so that we can
correctly convert past dates? I think so, as long as the table doesn't
lengthen *too* frequently. Your thoughts?
Also, can anybody comment on the rumored overhaul of the date-time services
for VMS 5.0? Has all this been done already, and are we wasting bandwidth
on a non-issue? Inquiring minds want to know.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 III U U PPPP U U III
Indiana University - Purdue University at Indianapolis I U U P P U U I
799 West Michigan Street, ET 1023 I U U PPPP U U I
Indianapolis, IN 46202 USA I U U P U U I
[@disclaimer@] III UUU P UUU III