epics vxworks time off by 1 hour

[Dennis Nicklaus <nicklaus@fnal.gov>]

The time that epics records for updates of my PVs in some vxworks nodes
is off by one hour.  This is the time seen by camonitor, the channel 
archiver, etc.

If I run the vxworks time() function which gives me seconds since 1970, 
the value returned
matches that returned by unix's time()  (/usr/include/time.h) on my unix 
nodes.

I run date() on  vxworks, I also get the correct date and time printed out.
This date() is apparently provided by EPICS since
   lkup "date"
finds it in my EPICS object .munch file.

so the system knows the proper date and time.

But somehow EPICS gets it wrong.  At Geoff's suggestion, I use the epics 
IOC shell function
 dbtgf "PV"
to print the update  time, along with other info like this
-> dbtgf "CC2_KLY:ildb0:wave9Flat"
status=0 severity=0
units=       
precision=4
time=558040636 315109960
...

And the first part of the time there is supposed to be seconds since Jan 
1 1990 (not 1970)
which should be 631152000 less than the time since 1970
(3600*24*(365*20+5leapdays)) = 631152000

Anyway, the time I get from dbtgf   is also exactly one hour earlier 
than it should be
(after I convert by adding 631152000 then comparing to unix's seconds 
since 1970).
The dbtgf time matches the camonitor time, both being one hour early.
I even tried to force things a bit by adding these lines to the 
beginning of my vxworks boot script:
putenv "TIMEZONE=PSTPDT::480:031102:110402"
putenv "EPICS_TS_MIN_WEST=480"
I'm really in the Central time zone, but I thought I would make it think 
I was Pacific time, just
to see what happens.
And after that on vxworks,
date() does print out the time as it should be in the Pacific zone (two 
hours earlier
than central), but when I do camonitor on my central time zone unix 
machine, it still
tells me the PV update time is one hour too early (one hour earlier than 
the actual CDT time here now).

I have run with and without the correct TIMEZONE setting, which is
putenv "TIMEZONE=CSTCDT::360:031102:110402"
but it doesn't make any difference, as well it shouldn't since we are in 
the middle of CST and not
on the newly-changed-this-year shoulder dates in March or Nov.

I get this behaviour with my epics objects built with 3.14.7 and 3.14.8.2.
(I had been running 3.14.7 but decided to upgrade since I thought maybe 
that was causing the problem here).
vxworks version 5.4

camonitor is 3.14.8.2 and the archiver is built against 3.14.8.2 I believe.


What do I have to do to get epics the correct time?

Thanks
Dennis
nicklaus@fnal.gov