18 Jan
2015
18 Jan
'15
5:04 p.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.
Mark L
18 Jan
18 Jan
5:07 p.m.
On 2015-01-19 02:04, Mark Longridge wrote:
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?
Actually RSX internally also handles it fine, but there were bugs in
various code that displayed dates, that assumed that the year would
never go beyond 99. :-)
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
7:30 p.m.
Believe is you use 1972, that is the folding point for the calendar to get
weeks and months correct.
Older versions of RSTS did not do it past about mid 2000.
John>
On Sun, Jan 18, 2015 at 6:07 PM, Johnny Billquist <bqt at update.uu.se> wrote:
On 2015-01-19 02:04, Mark Longridge wrote:
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?
Actually RSX internally also handles it fine, but there were bugs in
various code that displayed dates, that assumed that the year would never
go beyond 99. :-)
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
19 Jan
19 Jan
5:03 a.m.
On 2015-01-19 04:30, John Kaur wrote:
Believe is you use 1972, that is the folding point for
the calendar to get
weeks and months correct.
Older versions of RSTS did not do it past about mid 2000.
John
RSTS/E have some weird internal format that is really not very good, and
which soon will have problems again. It already did have problems, but
it was extended by explicitly saying that the date was unsigned. (The
date format is pretty much ((year-1972)*1000)+day within year. Which
obviously waste a lot of the values, as there are only 365 or 366 days
in a year. And of course, they hit problems 32 years after the start
year, which was 2004.)
I don't know what is special about 1972. I always assumed they used that
base because that's the year RSTS-11 first showed up.
Johnny
On Sun, Jan 18, 2015 at 6:07 PM, Johnny Billquist <bqt at update.uu.se> wrote:
> On 2015-01-19 02:04, Mark Longridge wrote:
>
>> 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?
> Actually RSX internally also handles it fine, but there were bugs in
> various code that displayed dates, that assumed that the year would never
> go beyond 99. :-)
>
> 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
>
--
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
8:32 a.m.
On Mon, 19 Jan 2015, Johnny Billquist wrote:
I don't know what is special about 1972. I always
assumed they used that
base because that's the year RSTS-11 first showed up.
That anniversary is as good a reason as any other.
1972 is one full cycle (28 years) before 2000.
1973's calendar matches (days of the week) with 2001,
1974 matches with 2002, 1975 matches with 2003, etc.
9:10 a.m.
On Mon, Jan 19, 2015 at 02:03:42PM +0100, Johnny Billquist wrote:
I don't know what is special about 1972. I always
assumed they used
that base because that's the year RSTS-11 first showed up.
Actually it's 1970 (but RT-11 uses 1972), and it's inherited from DOS/BATCH
which I think everyone knew was a stopgap, like most systems at the time ...
so it didn't plan ahead very well, even enough to multiply by 366. instead
of 1000. But yeah 1970 is pretty much the beginning of time as far as
PDP-11s in general (including DOS/BATCH) are concerned. At least this shows
more foresight than OS/8! I think at the time the culture really must
have been that computer architectures have a lifespan well under a decade,
just because that had largely been true so far. The S/360 was an anomaly.
John Wilson
D Bit
20 Jan
20 Jan
8:38 a.m.
On 19 January 2015 at 01:07, Johnny Billquist <bqt at update.uu.se> wrote:
TOPS-20? VMS?
Actually RSX internally also handles it fine, but there were bugs in various
code that displayed dates, that assumed that the year would never go beyond
99. :-)
IIRC there was a bug filed against VMS to the effect that dates past
9999 were not supported. Have to be impressed by that belief in future
engineering :)
I quite liked that the Gould UTC/32 system we used in 1987 had 32bit
padding around any stored filesystem timestamp to allow for moving to
64bit time, ahh ECL systems...
18 Jan
18 Jan
7:51 p.m.
On Sunday, January 18, 2015 at 20:04, Mark Longridge wrote:
So, did any operating system programmers from this
time period have
the foresight to use 4 digits for the year?
It's just outside of your time frame (circa 1980), but the HP 64000
operating system allowed years up to 2157 (dates were stored as the number
of days since January 1, 1976) and accepted years of either two or four
digits. Unusually for an American product, it required dates to be entered
in D/M/Y format.
-- Dave
19 Jan
19 Jan
5:04 a.m.
On 2015-01-19 04:51, J. David Bryan wrote:
On Sunday, January 18, 2015 at 20:04, Mark Longridge
wrote:
I think pretty much all DEC OSes normally used dd-mmm-yy, but some of
them could accept input in various format.
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
So, did any operating system programmers from
this time period have
the foresight to use 4 digits for the year?
It's just outside of your time frame (circa 1980), but the HP 64000
operating system allowed years up to 2157 (dates were stored as the number
of days since January 1, 1976) and accepted years of either two or four
digits. Unusually for an American product, it required dates to be entered
in D/M/Y format. 
18 Jan
18 Jan
11:07 p.m.
--On January 18, 2015 at 8:04:09 PM -0500 Mark Longridge
<cubexyz at gmail.com> wrote:
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.
MTS will work ok until the original IBM TOD clock overflows in 2042. I
think there were a few minor bugs that had to be fixed in 2000, but
most everything worked. I run MTS every now and then and haven't
noticed problems. Fixing it for 2042 will be a bigger problem if
anyone who cares is still around. Since STCK is a non-privileged
instruction finding and fixing the problems will be challenging.
Mike
19 Jan
19 Jan
12:05 a.m.
On Mon, Jan 19, 2015 at 02:07:59AM -0500, Mike Alexander wrote:
MTS will work ok until the original IBM TOD clock
overflows in 2042.
I always liked how the March 1/1900 starting point sidestepped the
leap-year ugliness.
Fixing it for 2042 will be a bigger problem if
anyone who cares is still around. Since STCK is a non-privileged
instruction finding and fixing the problems will be challenging.
The great thing about emulation is that you can make an instruction be
as thorny as you want, temporarily, to flush out stuff like this.
John Wilson, ETS4
D Bit
1:37 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of John
Wilson
Sent: 19 January 2015 08:05
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Operating systems of the 1970s handling dates beyond the year
2000
On Mon, Jan 19, 2015 at 02:07:59AM -0500, Mike Alexander wrote:
leap-year
MTS will work ok until the original IBM TOD clock
overflows in 2042.
I always liked how the March 1/1900 starting point sidestepped the ugliness.
When I tried an early date with Ultrix to make the day of the week correct
it said the date wasn't possible because it was before Ultrix was released.
I found a suitable date in 1998.
Regards
Rob
Fixing it for 2042 will be a bigger problem if
anyone who cares is
still around. Since STCK is a non-privileged instruction finding and
fixing the problems will be challenging.
The great thing about emulation is that you can make an instruction be as
thorny as you want, temporarily, to flush out stuff like this.
John Wilson, ETS4
D Bit
8:18 a.m.
On Mon, 19 Jan 2015, Robert Jarratt wrote:
When I tried an early date with Ultrix to make the day
of the week correct
it said the date wasn't possible because it was before Ultrix was released.
I found a suitable date in 1998.
Well, there are only 14 different calendars for the years - 7 different
ones for each starting day, and another 7 for leap years. Between 1901 and
2099, there is always a repeat every 28 years. But there are numerous
more. For THIS year (2105), you can get away with 1981, 1987, 1998, 2009,
. . .
(Note that 1900 and 2100 are not leap years because they are divisible by
100, but 2000 WAS a leap year, due to being divisible by 400.)
But, be careful when you reuse old wall calendars!
One of the first steps in a simple field sanity check is to ask the person
whether they know what the date is. One glance at my wall, with a 1981
calendar and computers and computer books and magazines that happen to
be from that time period, and they know that I don't.
--
Grumpy Ol' Fred cisin at xenosoft.com
3576
days inactive
3577
days old
12 comments
9 participants
participants (9)
-
abs＠absd.org -
bqt＠update.uu.se -
cisin＠xenosoft.com -
cubexyz＠gmail.com -
digitgraph＠gmail.com -
jdbryan＠acm.org -
mta＠umich.edu -
robert.jarratt＠ntlworld.com -
wilson＠dbit.com