[HECnet] US DST

Thomas DeBellis tommytimesharing at gmail.com
Mon Mar 9 12:17:41 PDT 2020


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.

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.

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.

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.

What's more likely has happened with respect to time formattong is 
cross-fertilization.  Operating systems have lifted ideas from each other.

 1. Sun OS, Linux and Windows took the memory mapped file paradigm from
    TENEX/Tops-20.
 2. Tab recognition for shells is right out of COMND% on Tops-20 (except
    all native Tops-20 programs have it).
 3. 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.
 4. Some good ideas have come from Multics, too.

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.

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).

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.

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.

> ------------------------------------------------------------------------
> On 3/9/20 6:40 AM, Dan Cross wrote:
>
> 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.
>
>         - Dan C.
>
>     ------------------------------------------------------------------------
>     On Sun, Mar 8, 2020, 9:42 PM William Pechter <pechter at gmail.com
>     <mailto:pechter at gmail.com>> wrote:
>
>     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.
>
>     Does anyone know if the assumption is true?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200309/8ca3fec4/attachment.html>


More information about the Hecnet-list mailing list