<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I agree with Dan. I'm not aware of William's speculation being
true and I strongly suspect it isn't true, although the point
about time formatting might be. I don't remember enough about
parsing time to have an informed opinion on Unix.</p>
<p>I first used Unix in the early winter of 1978 on a PDP-11/05 in
WPI's CS lab where I was an operator. A C class was being taught
by an early Unix enthusiast. We were impressed by certain things
yet remained underwhelmed. The performance was less than
compelling, some of the facilities appeared primitive and the
defaults for job control and editing characters weren't anything
like what we were used to. Unix was mostly never booted in favor
of running RSX or RT.</p>
<p>I don't remember any particular special handling of time or date
nor do I recall the C library of the time having any support for
the richness that exists today. Given the limitations of the
machines of the time, a significant portion of us couldn't
understand why you wouldn't want to use assembler. For myself, I
stuck with RT-11 on a PDP-11/40 in the Mechanical Engineering lab
(where I was also an operator). The 11/40 was a far faster
machine and it also had a GT40 on it. Very nice.</p>
<p>I don't see how the Unix on any 11 of the time (pre-11/70) would
have had the storage or bandwidth to do the processing William is
talking about. A careful examination of a Bell bill of time (to
see how we could reduce costs) led us to speculate that an IBM
mainframe running MVS was probably being used to do the billing.
That would have been one of the few systems around with the kind
of capacity to handle the datasets in question.</p>
<p>What's more likely has happened with respect to time formattong
is cross-fertilization. Operating systems have lifted ideas from
each other. <br>
</p>
<ol>
<li>Sun OS, Linux and Windows took the memory mapped file paradigm
from TENEX/Tops-20.</li>
<li>Tab recognition for shells is right out of COMND% on Tops-20
(except all native Tops-20 programs have it).</li>
<li>Tops-20 almost, but didn't quite have pipes and didn't have
relative directory specifications. It now has pipes, but the
relative directory specification needs a buff and polish.
That's clearly from Unix.</li>
<li>Some good ideas have come from Multics, too.<br>
</li>
</ol>
<p>With regards to time, as far as I am aware (meaning I don't know
about Multics), from its beginning, TENEX had the richest time
handling. The time was stored internally as two 18 bit half
words, the left half being the elapsed dates since midnight-GMT
November 17th, 1858 (this conforms with (the Smithsonian
Astronomical Date Standard). The right halfword is the number of
seconds elapsed since midnight. TENEX had a number of JSYI to
both parse, convert and print time using the local timezone. It
also has a certain amount of code to handle daylight savings time
and has had it since at least 1971.</p>
<p>Tops-20 has certain improvements and minor changes. Tops-20 has
a table to account for what year is being used in order to know
when the start and end of DST is (for example, double war time in
WWII). This was either written by or improved by MRC in the
1980's and allows us to handle the number of changes that happened
to the legislated start and end of DST over the years
(particularly during the energy crisis of the 1970's).</p>
<p>There is an interesting incompatibility in internal formats. It
will be noted that the number of seconds in a day can be stored in
17 bits, whereas the right halfword is 18 bits. DEC changed the
internal format for the elapsed time to be the binary fraction of
1/2**18, or about 1/3 of a second. This allows for simpler
arithmetic operations, which can essentially be done on a 36 bit
fixed point number. Unfortunately, it means that, when
transferring special pages between TENEX and Tops-20 using FTP,
you have to format the times in ASCII. Tops-20 will run out of
time on 7-Aug-2576 19:59:59, a sad day indeed.</p>
<p>Having nicer time output just seems like a logical progression of
nice ideas. It's hard to tell where Unix got it from. I think it
probably showed up in the C library first, but I don't know why.
It could have been from Tops-20, but maybe VMS beat Unix to the
punch and Unix got it from there. There was a certain amount of
cross-fertilization between Ultrix and Tops-20, less so between
VMS and Tops-20, which is unfortunate.<br>
</p>
<blockquote type="cite"
cite="mid:CAEoi9W7xMxh9sDb1FU+eib8tDD5BWOYadHsCUuKF2u0=WKYa8A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">
<hr width="100%" size="2">On 3/9/20 6:40 AM, Dan Cross
wrote:</div>
<br>
</div>
</div>
<div dir="auto">I've never heard that before but I doubt it's
true. Most of the interesting timezone-related work on Unix
was done outside of the labs. I think in the research Unix
days it was rather more primitive, and besides, that group was
not focused on telephone billing.</div>
<div dir="auto"><br>
</div>
<div dir="auto"> - Dan C.</div>
<div dir="auto">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<hr width="100%" size="2">On Sun, Mar 8, 2020, 9:42 PM
William Pechter <<a href="mailto:pechter@gmail.com">pechter@gmail.com</a>>
wrote:<br>
<br>
Interesting how Unix seems to have done the most with
Timezone handling. My guess is it's because of the Bell
Systems interest in record keeping of CDR's
(Call-Detail-Records) for phone billing per minute charges
or message units. They probably kept the records in GMT and
just wrote the local time of call and length on the bills
when processing.<br>
<br>
Does anyone know if the assumption is true?<br>
</blockquote>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>