Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!kvc
From: kvc@nrcvax.UUCP
Newsgroups: comp.os.vms
Subject: Re: Changing from daylight time to standard time
Message-ID: <1256@nrcvax.UUCP>
Date: Thu, 29-Oct-87 16:43:38 EST
Article-I.D.: nrcvax.1256
Posted: Thu Oct 29 16:43:38 1987
Date-Received: Sun, 1-Nov-87 09:15:38 EST
References: <8710241907.AA29503@ucbvax.Berkeley.EDU> <946@nmtsun.nmt.edu>
Reply-To: kvc@minnie.UUCP (Kevin Carosso)
Organization: Network Research Corp.  Oxnard, CA
Lines: 49

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