I've been giving more thought to the TZ environment variable on
MPE/iX.  Many of you in the Northern Hemisphere changed the clocks on
your MPE machines last weekend.  At least I assume that you did.

I know that the Robelle system managers made the change over the
weekend (thanks to Jeff Vance and everyone at HP for the nifty
setclock/gradual change functionality).  What does this have to do
with TZ?

On most UNIX systems, the TZ environment variable indicates your
relative time location to GMT.  For the West Coast, you would
typically have the value:

     TZ=PST8PDT

This says we are Pacific Standard Time, eight time zones from GMT (I
forgot whether this is plus or minus, but you get the idea).  It
*also* says, add an extra hour for Daylight Savings Time.  This is a
good thing in UNIX, since UNIX system managers do *not* change the
system date when daylight savings time comes into affect.

As we develop and deploy more POSIX and C-based tools, we have to get
the TZ environment variable correct.  On our MPE/iX machines, we just
used the value we had on our HP-UX machines:

     TZ=PST8PDT

But is this correct?  I know that for our site, this is not the right
thing to do.  Since the "real" clock was adjusted by an hour last
weekend or at least the clock that the C and POSIX run-time routines
see, we shouldn't adjust for DST yet again.  I did some quick testing
earlier this week that seemed to conclusively show that at least for
the C/iX run-time routines, TZ should be set to:

     TZ=PST8

(note that "PDT" was left off).  Am I missing anything obvious?  Or
are most of you not changing your clocks (hard to imagine since most
of MPE/iX isn't written in C and thus rely on the calendar intrinsic
to return the "true" local time).  Or more likely, are few of you
using any C or POSIX developed tools that rely on TZ?

Cheers,

David <[log in to unmask]>