[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]

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