Xref: utzoo alt.folklore.computers:12412 comp.unix.wizards:25844
Path: utzoo!utgpu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!dcl-cs!gdt!exspes
From: exspes@gdr.bath.ac.uk (P E Smee)
Newsgroups: alt.folklore.computers,comp.unix.wizards
Subject: Re: So, anyone got an imitation Multics 'memo' command?
Message-ID: <1991Jun3.111321.18095@gdr.bath.ac.uk>
Date: 3 Jun 91 11:13:21 GMT
References: <45919@cos.com>
Reply-To: P.Smee@bristol.ac.uk (Paul Smee)
Organization: University of Bristol c/o University of Bath
Lines: 32

In article <45919@cos.com> fetter@cos.UUCP (Bob Fetter) writes:
>  Also, isn't there a convert_date_to_binary_$relative_time rtn (or
>something similar) which just parsed time deltas from current time?
>I'm thinking of memo's "-repeat 2 weeks" argument.  Or was that just
>a degenerate case of not giving a base time along with the delta in
>the string?  It *has* been a while (longer than I really care to think
>about)...

Almost, but backwards.  cdtb_ took a character string and gave back a
fixed bin (71) system date-time and an error code.  cdtb_$relative took
a char string and an fb(71) system date-time, and gave back an fb(71)
system date-time and an error code.

Both worked the same if the character string was an absolute date/time,
e.g "10:15 AM March 3 1992".  If the string was a relative date/time
(e.g. "March 12", which meant the NEXT occurance of March 12 after the
reference date/time, or "+5 days" which means 5 days from the
reference date/time) then cdtb_ would do the calculation using the
current system clock as the reference time, while cdtb_$relative would
use the passed-in clock value as the reference date/time.

In fact, as I recall, since PL/1 allowed multiple entry-points to a
procedure, the implementation was simply that cdtb_ read the system
clock and then fell through into the cdtb_$relative case.  The epoch
was set at 0000. GMT 1 Jan 0001 AD, and cdtb knew about dates from Jan
1 0001 AD thru to Dec 31 9999 AD, resolution down to the microsecond.
(It is pointed out as a limitation, though, that it did NOT know about
leap-seconds.)

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132