12 Dec
2017
12 Dec
'17
6:01 p.m.
Heh, my V6 machine thinks (via 'date') that today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the
date code is probably missing the '400 year' exception.
Noel
12 Dec
12 Dec
6:21 p.m.
The date on my Venix system doesn't grok 20xx at all. I had to hack date.c
from v7 to make it work. So at some point you had to hack things in to make
20xx work, no?
Warner
On Tue, Dec 12, 2017 at 11:01 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
Heh, my V6 machine thinks (via 'date') that
today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the
date code is probably missing the '400 year' exception.
Noel
13 Dec
13 Dec
3:07 p.m.
Seeing this thread (and in particular the "no long" versions of the date
code) got me thinking, how could the 2038 problem be solved for classic
unix?
Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get
to Y10K and is coincidentally as far as my ad-hoc implementation of
dividing by 86400 got) structure? How to encode times within 32-bit
fields on filesystems and such? Is it even worth it to do a fully
general implementation rather than simply treating it as unsigned,
delaying the problem until 2106?
And, for that matter, would a full implementation of modern time zone
data code (2.11BSD has one from a while back, though only supporting
32-bit times) be too large for smaller 16-bit unix systems?
On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote:
Heh, my V6 machine thinks (via 'date') that
today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
the
date code is probably missing the '400 year' exception.
Noel
5 p.m.
Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6
06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes
size wise.
I did 4.3BSD a long while back, and the only thing I really changed was the date command
so I could enter 4 year dates, otherwise everything seemed to run fine in the year 2040.
Sent from Mail for Windows 10
From: Random832
Sent: Wednesday, 13 December 2017 11:08 PM
To: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] Date madness
Seeing this thread (and in particular the "no long" versions of the date
code) got me thinking, how could the 2038 problem be solved for classic
unix?
Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get
to Y10K and is coincidentally as far as my ad-hoc implementation of
dividing by 86400 got) structure? How to encode times within 32-bit
fields on filesystems and such? Is it even worth it to do a fully
general implementation rather than simply treating it as unsigned,
delaying the problem until 2106?
And, for that matter, would a full implementation of modern time zone
data code (2.11BSD has one from a while back, though only supporting
32-bit times) be too large for smaller 16-bit unix systems?
On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote:
Heh, my V6 machine thinks (via 'date') that
today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
the
date code is probably missing the '400 year' exception.
Noel
5:18 p.m.
If I recall correctly, the original time system call used a pointer to two (16-bit) ints
rather than a long. Time was maintained in the kernel that way as well.
There are other systems that ran out of “time” a long time ago. The TOPS-10 software ran
out in 1975 or so if I recall. The Apollo domain/os ran out of time as well but I think
the whole OS became obsolete before it’s time function. The last release of the OS came
out eight years earlier.
6:02 p.m.
On 12/13/2017 12:18 PM, Ron Natalie wrote:
The TOPS-10 software ran out in 1975 or so if I
recall.
Nope, I can boot a 7.03 monitor and it understands Y2K and higher. I had
to edit SYSTAT.MAC to make it print the currect year after 2000, but
everything else just worked.
I believe a 6.03A monitor also behaves correctly.
Although, I believe the year is coming soon when it will implode and
wrap back around. I don't recall the specifics of that.
../simh/simhv28/pdp10 ks10.cfg.gold
PDP-10 simulator V2.8-4
Listening on socket 6
Modem control activated
sim> boot rp0
BOOT V3(47)
BOOT>
[Loading from DSKB:SYSTEM.EXE[1,4]]
LIRICS Timesharing Gold 07-08-01
Why reload: PM
Date: *<ENTER here takes date from hardware **clock>*
Time: *<ENTER here takes time from ***hardware ***clock>*
Startup option: go
*<snip>*
.SYS
Status of LIRICS Timesharing Gold at 12:59:09 on 13-Dec-2017
Uptime 3:17, 99% Null time = 99% Idle + 0% Lost, 0% Overhead
12 Jobs in use out of 128. 12 logged in, 10 detached.
*<snip>
*.
Monitor LIRICS Timesharing Gold
System uptime :04:08
Current date/time 13-Dec-2017 13:00:00 *<-- This time is spewed by the
monitor directly which I did not have to change>*
**
3:39 p.m.
Hi,
years ago I fixed some overflow bugs in v6. The file ctime.README
reads:
This tape (see enb.README) fixes some y2k and integer overflow issues
in V6.
ctime.c: Use Central European Timezone
ctime():
Don't blindly assume "19" to be the first two digits of the year.
gmtime():
The division of the current time by 8 hours overflows nowadays.
Instead divide by
24 hours, and use a routine which computes the quotient and remainder
with unsigned double word arithmetic. (ludiv())
If you want to understand ludiv and know modern program notations
have a look at ludiv.README.
date.c: Interpret the user entered year "00" as "2000", not as
"1900”.
The fixes are distributed on v6-tar tapes enblocked for simh (*.enb)
I think, the enb-directory is archived at tuhs. If not, let me know.
Here is the enb.README:
The contents of this directory are .README and .enb files with the
following basenames:
ctime: Some y2k related changes to V6.
dcheck: Bug fix and enhancement of dcheck.
dist: The V6 distribution tape: dist.README explains how to install
and setup V6 in the Supnik simulator. The file dist.enb is missing
for copyright and space reasons, you have to prepare it yourself.
(see enb.README).
dotdot: Kernel enhancement: If in a root directoy of a mounted filesystem,
let ".." mean the parent of the mount point, not the root directory.
enb: Conventions and usage of .enb files. Contains C-source of a program
which prepares tape files for the Supnik simulator and tells you
how to get the V6 distribution tape.
ludiv: Derivation of a double word unsigned division algorithm, which is used
in ctime. (no corresponding .enb)
man: The man command, which was missing from the distribution, and some
changes do make nroff output readable on an xterm.
Have fun,
Wolfgang Helbig
Stauferstr. 22
71334 Waiblingen
14 Dec
14 Dec
12:57 a.m.
On Tue, 12 Dec 2017, Noel Chiappa wrote:
Heh, my V6 machine thinks (via 'date') that
today is _Monday_, December
12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess
the date code is probably missing the '400 year' exception.
I fixed a Y2K bug once, when I found some code that baldly asserted that
2000 was *not* a leap year (and written by my then boss, no less).
Oh, I was also on duty around 0700 on 1/1/2000, just in case; yeah, there
were a couple of minor glitches, such as printing cheques for the year
19100...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
2:09 p.m.
During my first few years in the Unix room (starting in 1988) there was what seemed
like a semiannual flurry of leap year corrections made to research unix. Apparently,
there
was some aspect that kept misbehaving, with new bugs appearing at the next shift in time.
I never bothered to investigate the specifics, but it happened over several years. There
are
probably some on this list who know more details.
I don’t recall this being a problem on Plan 9.
ches
17 Dec
17 Dec
4:19 p.m.
Year corrections? Don't recall that but there were a bunch of changes to handle the
insertion of leap SECONDS over the years.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of William Cheswick
Sent: Thursday, December 14, 2017 9:10 AM
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Date madness
During my first few years in the Unix room (starting in 1988) there was what seemed like a
semiannual flurry of leap year corrections made to research unix. Apparently, there was
some aspect that kept misbehaving, with new bugs appearing at the next shift in time.
I never bothered to investigate the specifics, but it happened over several years. There
are probably some on this list who know more details.
I don’t recall this being a problem on Plan 9.
ches
4:33 p.m.
No, these weren’t seconds updates (though Plan 9 has a list it applies.) These were
off-by-one-hour problems at each time shift. There would be a sudden flurry of
hard, indignant work, then repeat next time shift. This was in V10 Unix.
On 17Dec 2017, at 11:19 AM, Ron Natalie
<ron(a)ronnatalie.com> wrote:
Year corrections? Don't recall that but there were a bunch of changes to handle
the insertion of leap SECONDS over the years.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of William Cheswick
Sent: Thursday, December 14, 2017 9:10 AM
Cc: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Date madness
During my first few years in the Unix room (starting in 1988) there was what seemed like
a semiannual flurry of leap year corrections made to research unix. Apparently, there was
some aspect that kept misbehaving, with new bugs appearing at the next shift in time.
I never bothered to investigate the specifics, but it happened over several years. There
are probably some on this list who know more details.
I don’t recall this being a problem on Plan 9.
ches
5:54 p.m.
On Sun, Dec 17, 2017, at 11:33, William Cheswick wrote:
No, these weren’t seconds updates (though Plan 9 has a
list it
applies.) These were off-by-one-hour problems at each time shift.
There would be a sudden flurry of hard, indignant work, then repeat
next time shift. This was in V10 Unix.
That'd be daylight savings, then, not leap years. 1987 was the year that
the US changed the date of the time shift from the last sunday of April
to the first.
The V10 source in the archive has an "octime.c" and "ctime.c", which
differ in the "sunday" function:
/*
* The argument is a 0-origin day number.
- * The value is the day number of the last
- * Sunday before or after the day.
+ * The value is the day number of the next
+ * Sunday after the day.
*/
static
sunday(t, d)
register struct tm *t;
register int d;
{
if (d >= 58)
d += dysize(t->tm_year) - 365;
- return(d - (d - t->tm_yday + t->tm_wday + 700) % 7);
+ return(d + 7 - (d - t->tm_yday + t->tm_wday + 700) % 7);
}
The "daytab" table itself (read in from /lib/dst) is not available in
the archive - and even if it were, we can't know the history of how it
was maintained or whether the 'flurry of hard work' involved maintaining
this file, making that change to the ctime routine, or recompiling
programs that needed it (and had been missed in a previous round).
10:15 p.m.
On Sun, 17 Dec 2017, Random832 wrote:
That'd be daylight savings, then, not leap years.
1987 was the year that
the US changed the date of the time shift from the last sunday of April
to the first.
You should try living in Australia :-) It was a political plaything for
quite a while, until it finally stabilised (except for the Sydney Olympics
in 2000). Neither QLD nor WA have it. Broken Hill, a city in NSW,
observes Central Time. And there was something odd about the railway line
at Echuca at one time (did it observe Central Time once, despite being in
VIC?)...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10:54 p.m.
On 2017-12-18 09:15, Dave Horsfall wrote:
You should try living in Australia :-)
And then there's Canada, which always follows what the US does, after 1
or 2 years of bickering and pretend independence. Can't risk the trade.
--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.
16 Dec
16 Dec
6:12 p.m.
Hi Noel,
may I draw your attention to
http://www.tuhs.org/Archive/Distributions/Research/Bug_Fixes/V6enb/ ?
There you'll find some modification to Unix V6. They are distributed as what I call
.enb. This suffix stands for “enblocked”. Enblocking means marking blocks on a tape file
suitable for simh. You’ll find more about V6 and the modifications at
http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/
Greetings,
Wolfgang Helbig
Stauferstr. 22
71334 Waiblingen
2328
days inactive
2333
days old
14 comments
10 participants
participants (10)
-
Arthur Krewat -
Dave Horsfall -
Ian Zimmerman -
Jason Stevens -
jnc＠mercury.lcs.mit.edu -
Random832 -
Ron Natalie -
Warner Losh -
William Cheswick -
Wolfgang Helbig