Experimental Physics and
Industrial Control System

"Laznovsky, Michael" <[email protected]> · Sun, 4 Mar 2007 23:24:55 -0800

Hi- we have a number of hard IOCs running 3.13.6 on vxWorks, and 
are wondering how best to approach the upcoming unusual time change.

Staring at the code reveals the following:

EPICS_TIMEZONE is not used in 3.13.6.

TS_MIN_WEST is initialized at compile time to 7*60=420 (US MST; ie. 
Chicago/FNAL), and then set to EPICS_TS_MIN_WEST at run time, if that's 
defined.  Used by UTC<->local-time conversion routines in tsSubr.c, 
and thus also by things like timestampRecord.c (local "timestamp" DB 
records).

TIMEZONE is set in base/src/db/drvTS.c but not referenced anywhere 
else.  If not already defined at iocInit(), it gets set to 
"UTC::<EPICS_TS_MIN_WEST>:040102:100102" (hard-coded).  Appears not 
to be used for anything after that... perhaps by vxWorks?  It does 
show up in "strings vxWorks" output.

As mentioned in http://www.aps.anl.gov/epics/tech-talk/2007/msg00063.php, 
there's no way to prevent the UTC<->local conversion functions from using 
the TS_DST_* #defines to add or subtract an hour on the OLD switch dates 
in April and October without modifying the code and recompiling base. 

So, one option is to reboot on March 11 with TS_MIN_WEST set to "420" 
(one time zone over), and then again on April 1st with the old normal 
"480" value.  Seems clumsy at best; what are other sites doing?

We need local time on IOC to be correct for timestamp records and the  
like; CA clients should be OK since that uses UTC... right?

Mike

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System