19 Jan
2015
19 Jan
'15
7:23 a.m.
After trying to get Unix v5 to understand dates
beyond the year 2000 I
had to wonder if any of the older operating systems from the 1970s or
older could do this.
So, did any operating system programmers from this time period have
the foresight to use 4 digits for the year? I just checked APL/360 and
it seems that it does not.
TOPS-20? VMS?
19 Jan
19 Jan
8:15 a.m.
On 2015-01-19 13:23, Peter Coghlan wrote:
It was very near the end of the 1970s but VMS made a really good effort to
handle times and dates well from the beginning. A single 64 bit time format
is used throughout the operating system and operating system routines are
provided to manipulate it and convert to and from well chosen standardised
display formats with no ambiguities such as two digit years or easily mixed up
numbers for days and months. Everything [*] displays and accepts the same
time and date formats and shortcuts such as YESTERDAY, TODAY and TOMORROW.
No messing about trying to figure out what format a particular utility wants
the date specified in and no wondering whether a unitless time displayed by
something is days, hours or minutes.
Agreed. But VMS was released in 1977. Possibly realy 1978, so it wasn't
"very near the end of the 70s" I think.
After trying to get Unix v5 to understand dates
beyond the year 2000 I
had to wonder if any of the older operating systems from the 1970s or
older could do this.
So, did any operating system programmers from this time period have
the foresight to use 4 digits for the year? I just checked APL/360 and
it seems that it does not.
TOPS-20? VMS?
The areas where I think it could have been done better
still are to have stored
the time internally in UTC rather than local time while displaying local time
and to have chosen an earlier base date than 17 November 1858. Also, there was
originally a rule that time differences could not be larger than 10000 days
which was poorly enforced and eventually had to be scrapped - this should have
been handled much more gracefully.
The local time problem is a serious miss that VMS did.
The 10000 day limit was a problem that hit the C runtime library, since
C programs like to, and expect code, to express time as an offset from
the epoch, which is Jan 1, 1970.
Of course, VMS used delta times for this, and that hit 10000 days a
little while ago, which barfed things up. I don't remember offhand
exactly what the solution looked like.
Nothing else normally ever had any issues with that limit, but I think
it was rather arbitrary, so I don't expect any programs had problems
with raising the limit either.
[*] A few system parameters are specified in seconds
and TIMEPROMPTWAIT is
specified in microfortnights with tongue in cheek.
:-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
12:13 p.m.
On Mon, Jan 19, 2015 at 02:15:38PM +0100, Johnny Billquist wrote:
The 10000 day limit was a problem that hit the C
runtime library,
since C programs like to, and expect code, to express time as an
offset from the epoch, which is Jan 1, 1970.
Of course, VMS used delta times for this, and that hit 10000 days a
little while ago, which barfed things up. I don't remember offhand
exactly what the solution looked like.
I don't either, but I do remember an *awesome* cover letter that DEC
sent out with the fix, assuring everyone that the libraries were now good
internally until some crazy year like 31078, but there was still formatting
code that assumed years fit in four digits so there would be Y10K bugs;
but don't worry, DEC will issue a patch to VMS at that time.
John Wilson
D Bit
6:28 p.m.
From: Peter Coghlan
Sent: Monday, January 19, 2015 4:24 AM
[failing to cite the previous posters, Mark Longridge and Johnny Bilquist]
ML:
>> After trying to get Unix v5 to understand
dates beyond the year 2000 I
>> had to wonder if any of the older operating systems from the 1970s or
>> older could do this.
>> So, did any operating system programmers from
this time period have
>> the foresight to use 4 digits for the year? I just checked APL/360 and
>> it seems that it does not.
JB:
> TOPS-20? VMS?
It was very near the end of the 1970s but VMS made a
really good effort to
handle times and dates well from the beginning.
Borrowing from TOPS-20 in the process, in spite of the VMS NIH mandate^Whabit.
The areas where I think it could have been done better
still are to have
stored the time internally in UTC rather than local time while
displaying local time and to have chosen an earlier base date than 17
November 1858.
The use of the modified Julian date (2,400,000.5 dates less than the
Julian date) dates to 1957, when the Smithsonian Astronomical Observatory
adopted it to track Sputnik in 18 bits on a 36-bit IBM computer. (Julian
dates, being used by astronomers, begin and end at noon rather than midnight.)
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
3472
days inactive
3472
days old
3 comments
4 participants
participants (4)
-
bqt＠update.uu.se -
cctalk＠beyondthepale.ie -
RichA＠LivingComputerMuseum.org -
wilson＠dbit.com