R021JM9W@VB.CC.CMU.EDU (Jim Murawski) (10/24/87)
In most of North America, standard time starts this Sunday
(October 25th) at 2:00. I have whipped up a command procedure
(that'll run in batch) to automatically change the system time
and notify the console that the time has changed. This same
procedure can also be used when changing from standard time
to daylight time. To submit it, type:
$ Submit Timechange /Parameter=("DAYLIGHT/STANDARD") -
/After="25-Oct-1987 02:00" /[Your favorite qualifiers]
In case your Vax is down at 2:00 on Sunday, the batch job will
still set your time back by 1 hour whenever the Vax comes back up,
so the time will still be correct. Note that you may lose "a
second or so" when changing the time via this procedure, but I'm
sure most of you will find it acceptable.
-Jim Murawski
-Carnegie Mellon Computing Services
-Pittsburgh, PA
-R021JM9W@VB.CC.CMU.EDU (or CMCCVB.Bitnet)
$! sys$user1:[r021jm9w]timechange.com;22
$! Last Edit Date = Fri Oct 23 16:50:12 1987 R021JM9W
$!
$! ** Revision History (Start) **
$! ---------------------------------
$! Fri Oct 23 16:50:12 1987 R021JM9W : Initial version.
$! ---------------------------------
$! ** Revision History (Finish) **
$!
$! TIMECHANGE - Change the time from Daylight to Standard or vice-versa,
$! depending on the value of P1 (parameter 1 in batch).
$!
$ Save_Ver = F$Verify (1)
$ On Error Then Goto ABORT
$ On Control_Y Then Goto ABORT
$ P1 = F$Edit (P1, "UPCASE,TRIM")
$ If P1 .EQS. "STANDARD/DAYLIGHT" Then Goto START
$ If P1 .EQS. "DAYLIGHT/STANDARD" Then Goto START
$ Goto ABORT
$START:
$ Prev_Priv = F$Setprv ("OPER,LOG_IO")
$ Cur_Timestamp = F$Time ()
$ Cur_Date = F$Cvtime (Cur_Timestamp, "ABSOLUTE", "DATE")
$ Cur_Hour = F$Cvtime (Cur_Timestamp, , "HOUR")
$ Cur_Minute = F$Cvtime (Cur_Timestamp, , "MINUTE")
$ Cur_Second = F$Cvtime (Cur_Timestamp, , "SECOND")
$ Cur_Hundredth = F$Cvtime (Cur_Timestamp, , "HUNDREDTH")
$ If P1 .EQS. "STANDARD/DAYLIGHT" Then Goto ADD_HOUR
$SUB_HOUR:
$ New_Hour = F$String (F$Integer (Cur_Hour) - 1)
$ Goto NEW_TIME
$ADD_HOUR:
$ New_Hour = F$String (F$Integer (Cur_Hour) + 1)
$NEW_TIME:
$ New_Timestamp = Cur_Date + " " + New_Hour + ":" + Cur_Minute + ":" -
+ Cur_Second + "." + Cur_Hundredth
$ Set Time="''New_Timestamp'"
$ Prev_Priv = F$Setprv (Prev_Priv)
$!
$! Notify the operator's console about the new time and send mail when OK
$!
$ Reply /Term=OPA0 /Bell -
"Changed system time from ''Cur_Timestamp' to ''New_Timestamp'"
$ Mail /Subject="Timechange OK!!" NL: "''F$Getjpi ("", "USERNAME")'"
$ Save_Ver = F$Verify (Save_Ver)
$ Exit
$ABORT:
$ Show Symbol $Status
$ Save_Stat = $Status
$!
$! Send mail on error and notify the operator's console
$!
$ Mail /Subject="Timechange Had Errors!!" NL: "''F$Getjpi ("", "USERNAME")'"
$ Reply /Term=OPA0 /Bell -
"ERROR changing system time, please call ''F$Getjpi ("", "Username")'"
$ Save_Ver = F$Verify (Save_Ver)
$ Exit Save_Stat
$!
$! End of TIMECHANGE.COMmwlcs423@nmtsun.nmt.edu (M. Warner Losh) (10/26/87)
In article <8710241907.AA29503@ucbvax.Berkeley.EDU>, R021JM9W@VB.CC.CMU.EDU (Jim Murawski) writes: > > In most of North America, standard time starts this Sunday > (October 25th) at 2:00. > [ much verbage deleted ] How about the command(s) : $ SET TIME="+01:00:00" ! In the fall $ SET TIME="-01:00:00" ! In the spring These work well and are much faster/easier to understand (they also work interactively.) One point I'd like to get straighten out. I've done this a few time, and have had no problems, but I'm not sure if it is cool. I have heard horror stories about people getting charged for one hour of cpu time when the system manager change the time on them. Has this ever happened to anyone under VMS? If so, then is there a better way of doing daylight savings stuff. I know this can mess up connect times, if your accounting software isn't smart enough, but we don't charge for connect time. Warner Losh
MADISON@CICGJ.RPI.EDU (Matt Madison) (10/26/87)
I wanted to make sure that the changeover was clean, so I scheduled a system shutdown for Sunday morning. Just before shutting down, I set the Sysgen SETTIME parameter to 1 (in the CURRENT parameters, of course). This parameter causes the time to be prompted for during system startup. After the system is up, you have to reset the SETTIME parameter to zero again, but other than that, it is a relatively painless, clean way to reset the system time. That is, if you can afford a system shutdown. Matt Madison Systems Programmer Center for Interactive Computer Graphics Rensselaer Polytechnic Institute
pete@tsc.dec.com (Pete Schmitt) (10/26/87)
In article <8710241907.AA29503@ucbvax.Berkeley.EDU>, R021JM9W@VB.CC.CMU.EDU (Jim Murawski) writes: > > In most of North America, standard time starts this Sunday > (October 25th) at 2:00. I have whipped up a command procedure > (that'll run in batch) to automatically change the system time This is a great idea, but you also have to shutdown decnet and bring it back up with the new time or it won't work for that hour. -- \\\!/// From: Pete Schmitt _ _ UUCP: allegra!decwrl!tsc.dec.com!pete ( Q Q ) DECnet: tsc::pete ---,,,,-------U-------,,,,--- It's okay to say the U... word.
david@elroy.Jpl.Nasa.Gov (David Robinson) (10/26/87)
Since everyone works out their favorite way to kludge DST why don't we all submit SPRs and get DEC to fix it once and for all. Simply have DEC maintain in kernel all times in a fixed timezone (GMT?) and have each site specify their timezone and if they are on DST. This way a file created on VAX A in London will appear to have the same creation date on VAX B in Los Angeles if it is transfered. As it is now with networks growing you can get files that have dates in the future. It appears that it can be implemented fairly easily so why not push for it in VMS 5.0 so we can all sleep at 2am each spring and fall. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ames!elroy!david UUCP Disclaimer: No one listens to me anyway!
art@MITRE.ARPA.UUCP (10/26/87)
I have changed time on a system which had accounting running. Yes I had people
who were charged for large amounts of connect time. I know of no one being
charged for an hour of CPU time. Clearly the person to receive this charge
if any one does, would be the account of the person who was executing at the
instant that the clock changed. This would be the system manager. However, I
understand that CPU time is billed on a clock tick basis to the person that
has the cpu at the time the clock ticks. It only increments a counter. It
would be two costly to take differences between the clocks at the begining
and end of the cpu usage.
The accounting package also will give a negative connect time for those
logged in during the Fall time change. This was actually the way that we
found out about the problem. A user received a credit for his usage for the
month after we corrected the CPU time. A DEC CE had entered the wrong year
and we were up and running before the mistake was noticed. Correcting the
time resulted in changing the year back by one. This resulted in a seventeen
thousand dollar credit for everyone who was logged in. We charge $2.00 per
hour of connect time. Which for 365 days came to $17,520. No one received a
CPU credit.
I will second the motion that it is best to take the system down. Second best
is to halt accounting and restart accounting after you change the time.
*
*---Art
*
*Arthur T. McClinton Jr. ARPA: ART@MITRE.ARPA
*Mitre Corporation MS-Z305 Phone: 703-883-6356
*1820 Dolley Madison Blvd Internal Mitre: ART@MWVMS or M10319@MWVM
*McLean, Va. 22102 DECUS DCS: MCCLINTON
*
=-=- This note is in response to yours which follows -=-=
In article <8710241907.AA29503@ucbvax.Berkeley.EDU>, R021JM9W@VB.CC.CMU.EDU (Ji
m Murawski) writes:
>
> In most of North America, standard time starts this Sunday
> (October 25th) at 2:00.
> [ much verbage deleted ]
How about the command(s) :
$ SET TIME="+01:00:00" ! In the fall
$ SET TIME="-01:00:00" ! In the spring
These work well and are much faster/easier to understand (they also work
interactively.)
One point I'd like to get straighten out. I've done this a few time,
and have had no problems, but I'm not sure if it is cool. I have heard horror
stories about people getting charged for one hour of cpu time when the system
manager change the time on them. Has this ever happened to anyone under VMS?
If so, then is there a better way of doing daylight savings stuff. I know
this can mess up connect times, if your accounting software isn't smart enough,
but we don't charge for connect time.
Warner LoshSYSRUTH@utorphys.BITNET.UUCP (10/27/87)
It affects only the connect time. CPU time used is not affected by time
of day. There are no great horrific effects otherwise. We *do* charge
for connect time, but it is an extremely small charge, so we ask people
to log off and if they still haven't after 2 minutes, they pay the
penalty. You may find that you won't be able to run accounting properly
until the time has caught up again since VMS accounting doesn't like
records being out of sync.
Ruth Milner
Systems Manager
University of Toronto PhysicsJMS%uamis@rvax.ccit.arizona.EDU.UUCP (10/27/87)
Of course, you all could come to sunny Arizona, where we don't believe in fooling with our clocks twice a year, and don't have to deal with such silliness! jms +-------------------------------------+ | Joel M Snyder | BITNET: jms@arizmis.BITNET | Univ of Sunny Arizona Dep't of MIS | Internet: jms@mrsvax.mis.arizona.edu | Tucson, Arizona 85721 | Pseudo-PhoneNET: (602) 621-2748 +-------------------------------------+ ICBM: 32 13 N / 110 58 W (I have gotten into trouble too many times to put any faith in disclaimers) "There's nothing here that an overdose of Seconal won't cure."
payne@watdcsu.UUCP (10/28/87)
In article <946@nmtsun.nmt.edu> mwlcs423@nmtsun.nmt.edu (M. Warner Losh) writes: > One point I'd like to get straighten out. I've done this a few time, >and have had no problems, but I'm not sure if it is cool. I have heard horror >stories about people getting charged for one hour of cpu time when the system >manager change the time on them. Has this ever happened to anyone under VMS? >If so, then is there a better way of doing daylight savings stuff. I know >this can mess up connect times, if your accounting software isn't smart enough, >but we don't charge for connect time. Don't know about accounting problems, but resetting the time sure screws up DECnet. For this reason, I never do it automatically. I first have to shut down the network (and various associated stuff). Then and ONLY then do I change the time. Doug
pete@tsc.dec.com (Pete Schmitt) (10/29/87)
In article <4026@watdcsu.waterloo.edu>, payne@watdcsu.waterloo.edu (Doug Payne) writes: > > Don't know about accounting problems, but resetting the time sure screws up > DECnet. For this reason, I never do it automatically. I first have to shut > down the network (and various associated stuff). Then and ONLY then do I > change the time. > > Doug That problem is fixed in 4.6 of VMS. -- \\\!/// From: Pete Schmitt _ _ UUCP: allegra!decwrl!tsc.dec.com!pete ( Q Q ) DECnet: tsc::pete ---,,,,-------U-------,,,,--- It's okay to say the U... word.
leichter@VENUS.YCC.YALE.EDU.UUCP (10/29/87)
Since everyone works out their favorite way to kludge DST why don't we all submit SPRs and get DEC to fix it once and for all. Simply have DEC maintain in kernel all times in a fixed timezone (GMT?) and have each site specify their timezone and if they are on DST. This way a file created on VAX A in London will appear to have the same creation date on VAX B in Los Angeles if it is transfered. As it is now with networks growing you can get files that have dates in the future. It appears that it can be implemented fairly easily so why not push for it in VMS 5.0 so we can all sleep at 2am each spring and fall. Have you though about what this would do in practice? If I create a file on my machine in New Haven, then move it to your machine in California, what does "the same time" mean? a) When we look at the timestamps, we see the same numbers. b) When we look at the timestamps, we see different numbers reflecting the same "time point" in our two areas. (a) is what happens today. It has a major advantage in that I can call you on the phone and check if you have "the latest version" - i.e., the one with a timestamp that is the same as mine. In general, it means that visible timestamps are invarient: They always look the same. (b) is what you would get if you stored all times in GMT - well, UCT if you want to get technical about it - and converted them to the local timezone every time you needed to display them. It means that (visible) timestamps on files change - you can't compare them across systems. Actually, it's worse than that: Suppose I create a file at about 5:00 the evening before the time change. The next morning, I try to find it. Guess what: The time displayed for the file is now not "about 5:00", but "about 4:00" (or "about 6:00"). While (a) has its drawbacks - such as "time travel" - (b) isn't a great blessing either - it can get very confusing. Imagine moving your mail file to a system in Japan and finding that all your old mail apparently arrived in the wee hours of the morning! A truely general solution would have to deal with a lot of related issues. For example, if I'm logged in to a machine in a different timezone, should I see times local to my terminal, or times local to the system? Imagine being logged in to a workstation, with a window SET HOST to a system in a different timezone. The only system I know of that seriously considered these issues was Multics. I don't know the details, but as a start each terminal had a "preferred time- zone" that would be used in producing time displays for it. But if you want a really complete job - and I don't know if Multics went this far - every time value in the system must carry with it an indication of the time zone in which it was created (but is it the system's time zone or the terminal the creator is logged into?) Then you can get meaningful displays that show that the file I just moved from New Haven to California was created at 8:23EST - or at 5:23 local time, if I prefer. Or at 6:23 if I'm dialed in from Salt Lake. (Oh, but don't forget that there is NO accepted standard for timezone abbrevi- ations - BST IS either Bering Strait Time or British Summer Time.) Simply changing to method (b) is something you can do today: Just set your system time to UCT and leave it there. Sure, the times on LOCAL files will look strange - but just think, all the files you transfer from London will be set up just right - except, of course, when England is on Summer Time! (Reminds me of the friend who's explanation of his odd schedule - he slept from about 4:00AM to noon - was, "Hey, millions of people are on the same exact schedule. It just happens that most of them are in England.") As for "SHOW TIME" being wrong - well, digital watches are pretty cheap! :-) A REAL fix would be a rather complex matter, and not something that "can be implemented fairly easily" for V5. Oh, and BTW, you'd STILL have to do something every Spring and Fall to change over from DST to ST. And don't suggest doing it automatically! There is no algorithm, fixed over time, that will tell you when to make the change - Congress keeps changing its mind, there have been local differences in the past - and that doesn't even MENTION the rest of the world, which follows its own (many) rules. Unix made the mistake of hard-coding an algorithm in at one point. Congress changed its mind. We had a number of systems running "in the next timezone over" for a while to compensate. -- Jerry ------
tedcrane@batcomputer.tn.cornell.edu (Ted Crane) (10/30/87)
In article <8710241907.AA29503@ucbvax.Berkeley.EDU> R021JM9W@VB.CC.CMU.EDU (Jim Murawski) writes: > I have whipped up a command procedure > (that'll run in batch) to automatically change the system time > and notify the console that the time has changed. This same > procedure can also be used when changing from standard time > to daylight time. To submit it, type: >...followed by a long and complicated command procedure... It's a great idea to have that command procedure, but the operant portion could be simplified somewhat along the lines: $ OLD_TIME = f$time() $ set time="+01:00:00" $ NEW_TIME = f$time() - ted crane, alias (tc) tedcrane@tcgould.tn.cornell.edu BITNET: tedcrane@CRNLTHRY {decvax!ucbvax}!tcgould.tn.cornell.edu!tedcrane DECnet: GOPHER::THC (607) 273-8768
kvc@nrcvax.UUCP (10/30/87)
In article <946@nmtsun.nmt.edu> mwlcs423@nmtsun.nmt.edu (M. Warner Losh) writes: > One point I'd like to get straighten out. I've done this a few time, >and have had no problems, but I'm not sure if it is cool. I have heard horror >stories about people getting charged for one hour of cpu time when the system >manager change the time on them. Has this ever happened to anyone under VMS? >If so, then is there a better way of doing daylight savings stuff. I know >this can mess up connect times, if your accounting software isn't smart enough >but we don't charge for connect time. > > Warner Losh Yes, this can indeed be a serious problem. When I was at Hughes, we had to charge for connect time. The big problem is, of course, that timewarps cause bogus elapsed, not CPU, time entries in ACCOUNTNG.DAT. Springing forward isn't so bad, as long as people don't complain too bitterly about the extra hour they got charged. Falling back, though, can lead to finish times that are before start times. Unfortunately, this causes the VMS accounting utility to produce bogus reports. I suppose you could write, or buy, some other report generator that kludges in something to account for the change. The simplest thing for me was to reboot with the new time. The fundamental problem is that VMS simply doesn't handle the situation at all. This has come up high on the list of SIR (System Improvement Requests) at DECUS but DEC is reluctant to solve the problem, stating "compatibility problems". It seems to me that a proper implementation would never change the binary system time. SYS$ASCTIM and SYS$BINTIM could take time-zone and DST information into account when digesting ASCII time strings for absolute times. The time-zone could even be settable on a per-process basis by a logical name or other mechanism, allowing remote users to select their own time-zone. What would a scheme like this break? Code which uses binary system times should be fine. Adding a time-zone field to ASCII times would be nice, but probably would break programs, so I wouldn't have $ASCTIM provide it by default. Utilities could be changed to get that field as programmer's time permits. About the only real problem I can see is how to decide when to apply DST offsets, since it can change at different times in different years, and perhaps at different times in different years for different time zones. This part of the algorithm would have to be pretty flexible. Someone tell me what's fundamentally wrong with this idea. I cannot believe that some lonely, bored VMS developer didn't already think up something like this late one night and promptly dismiss it. /Kevin Carosso kvc@nrcvax.uucp Network Research Co. nrcvax!kvc@trwind.trw.com
mitch@batcomputer.tn.cornell.edu (Mitch Collinsworth) (10/30/87)
In article <2753@batcomputer.tn.cornell.edu> tedcrane@tcgould.tn.cornell.edu (Ted Crane) writes: >In article <8710241907.AA29503@ucbvax.Berkeley.EDU> R021JM9W@VB.CC.CMU.EDU (Jim Murawski) writes: -> I have whipped up a command procedure -> (that'll run in batch) to automatically change the system time -> and notify the console that the time has changed. This same -> procedure can also be used when changing from standard time -> to daylight time. To submit it, type: ->...followed by a long and complicated command procedure... > >It's a great idea to have that command procedure, but the operant portion >could be simplified somewhat along the lines: > > $ OLD_TIME = f$time() > $ set time="+01:00:00" > $ NEW_TIME = f$time() The above would also keep you from getting bit by the bug you would hit in the original version if the batch job execution was delayed to the point where it tried to jump forward or back across midnite.