[TUHS] Date madness

[TUHS] Date madness

[Norman Wilson]

Arnold:

  ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
  for several years and I don't remember having to set the date / time
  every time I did a reboot.  They sat in a data center, so I may have never
  done a cold boot from power on.  It was a LONG time ago now, so there's
  undoubtedly lots that I just plain don't remember.

====

I believe all the VAXes had time-of-year clocks, though
the implementation and the method of access varied from
model to model.  On `Big' VAXes, the clock was considered
part of the console front-end, and accessed through the
model-specific console scheme.  MicroVAXes had no console
front-end; I believe the clock was accessed through
registers, but it was an off-the-shelf digital-watch
chip with some funny format (separate registers for
year, month, day, hour, minute, second).

So they all had proper battery-backed-up clocks, but of
many different types.  It wasn't as simple as reading a
single counter out of a register, sensible as that might
seem.

If anyone's really interested I can dig up details for
the several models of Big and MicroVAX I dealt with; I
still have all the code lying around.

Norman Wilson
Toronto ON

[TUHS] Date madness

[Chris Torek]

The 780 had only the Time Of Day Register (mfpr $TODR,reg),
but it covered more than a year's worth of "time of day":

    http://h41379.www4.hpe.com/wizard/wiz_1450.html
    http://rbur004.github.io/MacVAX/VAX-IPR/IPL_CLOCK.html

so the standard trick was to assume that the computer had
been booted within a year or so, and use the file system time
plus the TODR value to compute the correct time.

Various MicroVAXen may have added CMOS clock chips, and I vaguely
recall dealing wth BCD-encoded time on another VAX, perhaps the
8800.  I wrote some clock-chip driver code for the 4BSD SPARC port
and tried to consolidate the general issues of dealing with
multiple chip registers, two and four digit year encoding, BCD vs
decimal, and so on.

Chris

[TUHS] Date madness

[Ron Natalie]

I remember the fun and games when we had systems that went back and forth
between UNIX and VMS.    VMS set the time of day clock in local time.
UNIX set it to GMT.

[TUHS] Date madness

[Tom Ivar Helbekkmo]

Ron Natalie <ron at ronnatalie.com> writes:

> I remember the fun and games when we had systems that went back and forth
> between UNIX and VMS.    VMS set the time of day clock in local time.
> UNIX set it to GMT.

We used TGV Multinet to put our VAX/VMS cluster on the Internet.  Great
product, and really great service!  I loved the simple ingenuity of the
daylight savings switch on that system: for the forward shift in the
spring, it would run the system clock at double speed for an hour, and
for the autumn changeover, it would run it at half speed for two hours.
Since it took place during the night, it didn't bother anyone, and it
let the VMS system (which, as you say, ran on local time) maintain a
strictly increasing system clock at all times.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

[TUHS] Date madness

[Ron Natalie]

The VM systems at the UofM ran in local time.     There was no way to set
the time short of rebooting.
In the fall they'd announce.   System going down for reboot at 0130.   Back
up at 0100.

Amtrak has an amusing way of handling the time change.   A train just never
departs before it's published time.    This means in the spring; the trains
just tend to run an hour late (or later than normal).
In the fall, the train sits at whatever station it had arrived at before 2
AM and waits until the clock catches up.

[TUHS] OT: trains [Was: Date madness]

[Ian Zimmerman]

On 2017-12-17 15:07, Ron Natalie wrote:

> Amtrak has an amusing way of handling the time change.  A train just
> never departs before it's published time.  This means in the spring;
> the trains just tend to run an hour late (or later than normal).  In
> the fall, the train sits at whatever station it had arrived at before
> 2 AM and waits until the clock catches up.

How do other train systems handle it, e.g. the European intercity system?

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

[TUHS] OT: trains [Was: Date madness]

[Dave Horsfall]

On Sun, 17 Dec 2017, Ian Zimmerman wrote:

> How do other train systems handle [DST], e.g. the European intercity 
> system?

UTC?  It's not hard to get used to it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] OT: trains [Was: Date madness]

[Norman Wilson]

Ian Zimmerman:

> How do other train systems handle [DST], e.g. the European intercity 
> system?

Dave Horsfall:

  UTC?  It's not hard to get used to it.

=====

You misunderstand the problem.

Suppose I'm planning to board a train at 0300 on the morning
Daylight Time ends.

Now suppose the train actually departs an hour early, at 0200,
because it originated before the time change and some nerd who
never rides trains declared that it shall not wait the extra
hour until scheduled departure time.

Nerds may be happy, but the paying passengers won't be.  Telling
passengers to set their watches to UTC just won't happen.  (Some
of us nerds actually had our watches on GMT for a few months
back in the years that gave the `Nixon table' in old ctime.c
its (informal) name, but gave up because it was just too damn
much work to stay in sync with the real world.)

Once upon a time, before railways had radio communications and
proper track-occupancy signalling, the consequences were more
serious than that: if you run an hour ahead of schedule, you
risk colliding with another train somewhere.  That is why it
was the railways that first accepted and promoted standard time
zones.

Nowadays it's not about scheduling and safety, just about
having an acceptable user interface.

In a similar vein, I know of at least one case in which Amtrak
changed the official departure time of a train (that requires
advance reservations and often runs full) from 0000 to 2359,
because people would get confused about which day midnight
falls on and show up a day late.  (Actually the Amtrak
timetable read 1200 midnight and 11:59 PM, but 24-hour time
is one of the changes I agree people should just accept
and use.)

Norman Wilson
Toronto ON

[TUHS] OT: trains [Was: Date madness]

[Ian Zimmerman]

On 2017-12-18 08:03, Norman Wilson wrote:

> Suppose I'm planning to board a train at 0300 on the morning
> Daylight Time ends.
> 
> Now suppose the train actually departs an hour early, at 0200,
> because it originated before the time change and some nerd who
> never rides trains declared that it shall not wait the extra
> hour until scheduled departure time.
> 
> Nerds may be happy, but the paying passengers won't be.

Yes, this was the problem I was asking about.  Plus the even more vexing
problem of time discontinuity when the train is already en route.

I can still remember the days of thick bound paper schedules in Europe,
and I think for overnight routes there usually was a tiny footnote
about the 2 critical days.  New book schedules were issued each year so
the footnotes could be specific about the dates.  What I don't know is
how this transitioned into the digital age.

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

[TUHS] OT: trains [Was: Date madness]

[Dave Horsfall]

On Mon, 18 Dec 2017, Ian Zimmerman wrote:

>> Nerds may be happy, but the paying passengers won't be.
>
> Yes, this was the problem I was asking about.  Plus the even more vexing 
> problem of time discontinuity when the train is already en route.

Yeah, I misunderstood; sorry...  Hey, at least China doesn't have the 
problem of multiple timezones :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] OT: trains [Was: Date madness]

[Steve Mynott]

On 17 December 2017 at 21:24, Ian Zimmerman <itz at very.loosely.org> wrote:
> On 2017-12-17 15:07, Ron Natalie wrote:
>
>> Amtrak has an amusing way of handling the time change.  A train just
>> never departs before it's published time.  This means in the spring;
>> the trains just tend to run an hour late (or later than normal).  In
>> the fall, the train sits at whatever station it had arrived at before
>> 2 AM and waits until the clock catches up.
>
> How do other train systems handle it, e.g. the European intercity system?

A thread on https://www.railforums.co.uk/threads/about-the-clocks-going-forward.43348/
suggests the UK practice (at least in 2011) as documented in the
"Weekly Operating Notice" for the time change week is:

"trains to due to commence their journey before 0100 should run as if
GMT still applies. Trains due to commence their journey at or after
0200 will run at BST. Train crew booking on times should be adjusted
accordingly. Any times between 0100 and 0200 should clearly indicate
whether they are BST or GMT."

A quick google suggests other railway companies might generally handle
this problem differently with Sweden claimed to use the Amtrak
solution of waiting an hour so probably domestic European train
practice differs.

I would guess international trains might function as aircraft and use
local time. The timetabling for such trains is more likely to
regularly use different time zones anyway.

I wonder how Amtrak handles different time zones within the US?

-- 
4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>

[TUHS] Date madness

[Doug McIlroy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

>>>  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.
>>
>> Easy, but perhaps unwise. The sign bit is a potential escape hatch for
>> times, just as it is for characters in UTF-8.
> 
> I'm not sure what you're suggesting - UTF-8 works because it's a
variable length encoding - a variable length timestamp might be
interesting as an academic exercise, but there's no way for time() to
specify how much space is needed, or be informed of how much space is
allocated

Like UTF-8, a variable-length time would be something normal
programs aren't supposed to see--it would be a format for
external media (i.e. file systems). Times in inodes would be
variable-length. Times returned by stat() and time() would
be full length. Only the kernel needs to know the encoding.

One may note that inodes already use a variable-length
encoding for the list of physical block addresses, so there 
is nothing radical here.

I admit, though, that if the kernel can tell "old" from "new"
inodes, then they could have different time encodings rather
than one variable-length encoding.

Doug

[TUHS] Date madness

[Random832]

On Sat, Dec 16, 2017, at 05:50, Doug McIlroy wrote:
> Like UTF-8, a variable-length time would be something normal
> programs aren't supposed to see--it would be a format for
> external media (i.e. file systems). Times in inodes would be
> variable-length. Times returned by stat() and time() would
> be full length. Only the kernel needs to know the encoding.
> 
> One may note that inodes already use a variable-length
> encoding for the list of physical block addresses, so there 
> is nothing radical here.
> 
> I admit, though, that if the kernel can tell "old" from "new"
> inodes, then they could have different time encodings rather
> than one variable-length encoding.


I actually thought about this some more since making my previous post,
though I hadn't connected it to your post since I'd thought we were
still talking about the userspace interface.

One way the kernel could tell old from new inodes is by reserving the
high bit of one of the current 32-bit fields (either time, or size since
IIRC an existing inode can't actually hold a 2GB file) as a flag. My
initial thought was to simply encode in place (stealing some bits from
atime for the flag and high bits of ctime, and exploiting the
relationship that ctime<=mtime<=atime)

Or a whole "extended inode", that occupies two (or more) inodes on disk,
either adjacent to each other or by stealing a whole field as an inode
pointer.

Speaking of the address list, it looks like there's an unused byte in
the on-disk address list, which is 40 bytes for 13*3=39 bytes of
addresses

(The above is for V7 - V6 inodes are smaller and have less unused space)

Making this robust to being mounted by old kernels (and preventing old
kernels from creating files that would appear to new kernels to have
extended inodes) is the hard part, and I haven't thought any about what
the format of an extended inode would be.

[TUHS] Date madness

[Ralph Corderoy]

Hi Randy,

> One way the kernel could tell old from new inodes is by reserving the
> high bit of one of the current 32-bit fields

When Doug mentioned the high bit being an escape I assumed something
like, using eight bits for ease,

    00-7f  existing positive meaning
    80-df  new meaning as if unsigned
    e0-ff  existing negative meaning

    existing  80 81...df e0...fe ff 00 01...7f
    new                  e0...fe ff 00 01...7f 80 81..df

This would extend the positive range beyond 2038, but keep a small range
of negatives for their existing pre-1970 meaning.  This is storage
representation.  Calculations can be done in a wider int, with
intermediate values simply being signed, as before.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] Date madness

[Noel Chiappa]

    > From: Tom Ivar Helbekkmo

    > My /83s have them, but I'm not so sure it's a feature of the CPU board:
    > there's this thought nagging in the back of my head that the ToY thing
    > actually sits in the front panel module with the various buttons on it.

/83 documentation seems to be very thin on the ground, alas.

It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual
(EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User
and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84
Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a
different backplane, with QBUS/UNIBUS converter, so this could equally well be
titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock",
indicating the 83/84 don't have one.

Several companies made after-market ToD clocks to plug into the QBUS, e.g.
here:

  https://www.ebay.com/itm/371284594072

Is something like that what your /83 has?

   Noel

[TUHS] Date madness

[Doug McIlroy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

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

Easy, but perhaps unwise. The sign bit is a potential escape hatch for
times, just as it is for characters in UTF-8.

Doug

[TUHS] Date madness

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

On Wed, Dec 13, 2017, at 14:12, Doug McIlroy wrote:
> >  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.
> 
> Easy, but perhaps unwise. The sign bit is a potential escape hatch for
> times, just as it is for characters in UTF-8.
> 
> Doug

I'm not sure what you're suggesting - UTF-8 works because it's a
variable length encoding - a variable length timestamp might be
interesting as an academic exercise, but there's no way for time() to
specify how much space is needed, or be informed of how much space is
allocated

Anyway, making it use an "unsigned" 32-bit value is a bit less trivial
on V7 (where AIUI there's an unsigned type and a long type, but not
both), but the following works - not tested on actual V7 yet, but works
with the values as int16_t/int32_t on a modern system

        /*
         * break initial number into days
         */
        hms = *tim % 86400;
        day = *tim / 86400;
        if(*tim < 0) {
            hms += 109696;
            day += 49709 + hms / 86400;
            hms %= 86400;
        }

47909 days + 109696 seconds = 2^32 seconds. The "extra day" is to ensure
hms is positive.

This is instead of the existing hms < 0 clause

Making V6 do it (no long *or* unsigned type) is a bit more involved, but
I'm close to something viable. Incidentally, one gotcha I've run into is
that the code as-is passes the year minus 1900 to dysize, whereas modern
dysize implementations that respect the 100 and 400 year rules require
the full year.

My current attempt to extend it to more bits without resorting to
floating point relies on the fact that 86400=675*128 to eke out an extra
seven bits without implementing a general purpose division algorithm,
which gets it as far as the year ~10680 (~19391 unsigned). Though
without a long for the day count, V6 can only get to 2149.

[TUHS] Date madness

[Random832]

On Wed, Dec 13, 2017, at 22:07, Random832 wrote:
> Making V6 do it (no long *or* unsigned type) is a bit more involved, but
> I'm close to something viable. Incidentally, one gotcha I've run into is
> that the code as-is passes the year minus 1900 to dysize, whereas modern
> dysize implementations that respect the 100 and 400 year rules require
> the full year.

I managed to get it working - an implementation that works on V6 (well,
works on apout with the V6 compiler and library) for all dates between
1970-01-01 and 2106-02-07 06:28:15. I even tried to do as much as
possible in the register variables, to approximate the same performance
as the original (though I suspect the O(N) year incrementing loop
probably doesn't perform as well now as it did in 1975, especially with
a proper dysize implementation)

Other features: localtime supports all correct US rules and offsets
greater than 9 hours (though it still has the US rules and EST
hardcoded), and ctime supports Y2K (and 2.1K)

If anyone wants it I can post it somewhere, or just put it on the list.

[TUHS] Date madness

[Noel Chiappa]

    > From: Arnold

    > One would think that SIMH

I'm using Ersatz-11...

    > into the simulated computer's time of day clock.

What Time of Day clock? We're talking PDP-11's here! :-)

The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
none of their others did. And of course V6 long pre-dated the /93-94.

   Noel

[TUHS] Date madness

[Tom Ivar Helbekkmo]

Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:

> The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
> none of their others did. And of course V6 long pre-dated the /93-94.

My /83s have them, but I'm not so sure it's a feature of the CPU board:
there's this thought nagging in the back of my head that the ToY thing
actually sits in the front panel module with the various buttons on it.

Anyone with more specific knowledge?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

[TUHS] Date madness

[arnold]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>     > From: Arnold
>
>     > One would think that SIMH
>
> I'm using Ersatz-11...
>
>     > into the simulated computer's time of day clock.
>
> What Time of Day clock? We're talking PDP-11's here! :-)
>
> The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure
> none of their others did. And of course V6 long pre-dated the /93-94.
>
>    Noel

ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
for several years and I don't remember having to set the date / time
every time I did a reboot.  They sat in a data center, so I may have never
done a cold boot from power on.  It was a LONG time ago now, so there's
undoubtedly lots that I just plain don't remember.

(There was an old USENET joke about how with the size of transistors going
down, pretty soon you'd be able to get an S/370 inside your watch. But
of course, as soon as you booted MVS on it, it would ask you to set
the time! :-)

Arnold

[TUHS] Date madness

[Paul Winalski]

On 12/13/17, arnold at skeeve.com <arnold at skeeve.com> wrote:
>
> ISTR that the vaxen did have such things.  Or rather, I ran some BSD 780s
> for several years and I don't remember having to set the date / time
> every time I did a reboot.  They sat in a data center, so I may have never
> done a cold boot from power on.  It was a LONG time ago now, so there's
> undoubtedly lots that I just plain don't remember.

The first two VAXen, the 11/780 and 11/750, both had TOY clocks that
ran when the machine was powered off.  The 11/730 was designed to be a
low-cost VAX, and one of the ways they lowered the cost was
elimination of the TOY clock.  VMS (and I assume also UNIX) asked you
to enter the time whenever you cold booted the 11/730.

After the 11/730 came out, Dick Hustvedt (lead VMS architect and
engineer) and Stan Rabinowitz put together an elaborate April fool's
hack.  On April 1, the 11/730 in the VMS group's machine room had next
to it a pedestal with a sundial on it and a ribbon cable leading into
the 11/730, with sales brochures placed next to it.  The sales
brochures announced the SD730 Fixed Head Solar Horologue, a sundial
with a photocell for detecting noon that could be used to
automatically set the 11/730's time-of-day clock.  The thing actually
worked--it was connected via a UNIBUS real-time device controller, and
Hustvedt had written a VMS device driver for it.

All VAXen after the 11/730 had TOY clocks.

-Paul W.

[TUHS] Date madness

[Dave Horsfall]

On Fri, 15 Dec 2017, Paul Winalski wrote:

> After the 11/730 came out, Dick Hustvedt (lead VMS architect and
> engineer) and Stan Rabinowitz put together an elaborate April fool's
> hack.  On April 1, the 11/730 in the VMS group's machine room had next
> to it a pedestal with a sundial on it and a ribbon cable leading into
> the 11/730, with sales brochures placed next to it.  The sales
> brochures announced the SD730 Fixed Head Solar Horologue, a sundial
> with a photocell for detecting noon that could be used to
> automatically set the 11/730's time-of-day clock.  The thing actually
> worked--it was connected via a UNIBUS real-time device controller, and
> Hustvedt had written a VMS device driver for it.

Cripes; I remember that story!  Wasn't there a GIF of the brochure somewhere?

Ah, here's a reference:

     https://slashdot.org/comments.pl?sid=76256&cid=6805264

along with the dreaded microfortnights...

(Sad what happened to Dick.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Date madness

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3027 bytes --]

Apologies to Warren and the list for keeping this OT for UNIX thread going,
but it is history....

On Fri, Dec 15, 2017 at 11:41 AM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> The first two VAXen, the 11/780 and 11/750, both had TOY clocks that
> ran when the machine was powered off.  The 11/730 was designed to be a
> low-cost VAX, and one of the ways they lowered the cost was
> elimination of the TOY clock.  VMS (and I assume also UNIX) asked you
> to enter the time whenever you cold booted the 11/730.
>
> After the 11/730 came out, Dick Hustvedt (lead VMS architect and
> engineer) and Stan Rabinowitz put together an elaborate April fool's
> hack.  On April 1, the 11/730 in the VMS group's machine room had next
> to it a pedestal with a sundial on it and a ribbon cable leading into
> the 11/730, with sales brochures placed next to it.  The sales
> brochures announced the SD730 Fixed Head Solar Horologue, a sundial
> with a photocell for detecting noon that could be used to
> automatically set the 11/730's time-of-day clock.  The thing actually
> worked--it was connected via a UNIBUS real-time device controller, and
> Hustvedt had written a VMS device driver for it.
>
> All VAXen after the 11/730 had TOY clocks.
>
> -Paul W.
>

​As Paul and us ex-DECies remember, that hack lived on for years.   The ZK0
site (*a.k.a.* Spitbrook Road in Nashua, NH) was nominally DEC's SW
bldging.   At each site, there was a theme for naming the conference rooms;
*i.e.* LK0 (Littleton King St) it was towns/villages in New England.
It conference room being so name had a nice touch and much more fun than a
boring naming scheme of SITE_BLD-FLOOR-RM#-SIZE (such as Intel). **  The
ZK0 site theme had been historically famous people from science and
mathematics (CS, *etc*.).   Each room had painted on a wall a little
history about the person(s) and was 'dressed' with something, usually on
the walls, to depict one of their infamous ideas/inventions (e.g. Babbage
had difference engine, Ada, had pictures of things she used to program it,
I've forgotten what was in von Nueman but you get the idea).  After his
accident, one of the large conference rooms in VMS land, was renamed ​Hustvedt
and had the SD730 in the corner along with the story.   When we (Intel)
moved out the building, HP was closing shop in large sites in NE.   They
had already sold the bldgs to the local real-estate firm that sublets
them.  I've often wondered what happened to those rooms and in particular
the SD730 itself.  That one really should be in the Computer Museum.

Clem



** For the couple of years after the team was sold to Intel but not
moved desks, *i.e.* still on the second floor of ZK2, we had kept the DECs
names of our two large conference rooms which actually had official Intel
names, but everyone still called them by their DEC names.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171216/d876a92e/attachment-0001.html>

[TUHS] Date madness

[Dave Horsfall]

On Wed, 13 Dec 2017, arnold at skeeve.com wrote:

> (There was an old USENET joke about how with the size of transistors 
> going down, pretty soon you'd be able to get an S/370 inside your watch. 
> But of course, as soon as you booted MVS on it, it would ask you to set 
> the time! :-)

A bit OT, I know, but how close would S/370 and Apple's iWatch be?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Date madness

[Lyndon Nerenberg]

> On Dec 15, 2017, at 7:39 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> A bit OT, I know, but how close would S/370 and Apple's iWatch be?

~25 MHz CPU on the 3[67]0?  I/O channel controller bandwidth to the peripherals in low megabytes/s?  16 MB of core.

Do you think your iWatch could support 200 VM/370 APL, or general MTS, terminal sessions? :-)

[TUHS] Date madness

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Fri, 15 Dec 2017, Lyndon Nerenberg wrote:

>> A bit OT, I know, but how close would S/370 and Apple's iWatch be?
>
> ~25 MHz CPU on the 3[67]0?  I/O channel controller bandwidth to the 
> peripherals in low megabytes/s?  16 MB of core.
>
> Do you think your iWatch could support 200 VM/370 APL, or general MTS, 
> terminal sessions? :-)

Touché :-)  I was just tickled by the OP's reference to an OS fitting 
inside a watch, and immediately thought of the iWatch (well, it runs iOS).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Date madness

[Dave Horsfall]

On Wed, 13 Dec 2017, Noel Chiappa wrote:

>    > into the simulated computer's time of day clock.
>
> What Time of Day clock? We're talking PDP-11's here! :-)

On V6 at least, the time was set from the mod time (?) in inode #1, as I 
vaguely recall, so it was "pretty close".  My memory is *really* dim 
here...  Or was that one of the zillions of custom mods at the time?.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Date madness

[Warner Losh]

On Wed, Dec 13, 2017 at 7:08 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Dec 2017, Noel Chiappa wrote:
>
>    > into the simulated computer's time of day clock.
>>
>> What Time of Day clock? We're talking PDP-11's here! :-)
>>
>
> On V6 at least, the time was set from the mod time (?) in inode #1, as I
> vaguely recall, so it was "pretty close".  My memory is *really* dim
> here...  Or was that one of the zillions of custom mods at the time?.


BSD falls back to this method if no TOD source is registered to get a time
to set.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171213/9eec1a8b/attachment.html>

[TUHS] Date madness

[Noel Chiappa]

    > From: Arnold

    > So how did you manage to lose a whole year? Time travel? :-)

No, I just haven't booted the V6 often in the last year, and when I did, I
never bothered to reset the time; so it was still on Nov, 2016.

	Noel

[TUHS] Date madness

[arnold]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>     > From: Arnold
>
>     > So how did you manage to lose a whole year? Time travel? :-)
>
> No, I just haven't booted the V6 often in the last year, and when I did, I
> never bothered to reset the time; so it was still on Nov, 2016.
>
> 	Noel

One would think that SIMH would pass the current real time of day
into the simulated computer's time of day clock.  Or is it like
a real cold boot where the power was off, no battery on the clock,
etc.?  Just wondering.

Thanks,

Arnold

[TUHS] Date madness

[Noel Chiappa]

    > So, I looked at the code, and the bug is not obvious.

Because there _was_ no bug!!! :-)

It was saying December 12 was a Monday because the _year_ was still set to
_2016_, and in 2016, December 12 _was_ a Monday!

{Smacks forehead!}

	Noel

[TUHS] Date madness

[arnold]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:

>     > So, I looked at the code, and the bug is not obvious.
>
> Because there _was_ no bug!!! :-)
>
> It was saying December 12 was a Monday because the _year_ was still set to
> _2016_, and in 2016, December 12 _was_ a Monday!
>
> {Smacks forehead!}
>
> 	Noel

So how did you manage to lose a whole year? Time travel? :-)

[TUHS] Date madness

[Noel Chiappa]

    > Guess the date code is probably missing the '400 year' exception.

So, I looked at the code, and the bug is not obvious. (The routine for
detecting leap years in V6's ctime.c is so minimalistic it actually works for
2000!)

The version I'm currently running had been worked on some, to have a hack fix
for the overflow of the number of 8-hour periods since the epoch ("hack" since
the 'fixed' version will break in 2029 or so), and I was worried that 'fix'
was wrong and caused the week-day problem, but I don't think so.

    Noel

[TUHS] Date madness

[Noel Chiappa]

    > From: Warner Losh

    > So at some point you had to hack things in to make 20xx work, no?

I had a number of date issues with V6; more here:

  http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues

That one was the easiest to fix! (Although this one will probably also be
pretty easy, too.)

	Noel

[TUHS] Date madness

[Noel Chiappa]

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

[TUHS] Date madness

[Warner Losh]

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171212/55222e74/attachment.html>

[TUHS] Date madness

[Random832]

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

[TUHS] Date madness

[Jason Stevens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171214/eaec3545/attachment.html>

[TUHS] Date madness

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

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.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171213/033cc0f2/attachment.html>

[TUHS] Date madness

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

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>*

**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171213/f23f82c0/attachment-0001.html>

[TUHS] Date madness

[Wolfgang Helbig]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

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

[TUHS] Date madness

[Dave Horsfall]

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

[TUHS] Date madness

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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

[TUHS] Date madness

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

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

[TUHS] Date madness

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

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 at 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 at 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
> 
> 

[TUHS] Date madness

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

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

[TUHS] Date madness

[Dave Horsfall]

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

[TUHS] Date madness

[Ian Zimmerman]

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.

[TUHS] Date madness

[Wolfgang Helbig]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

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