Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 05 Mar 2007 10:43:39 -0600

Laznovsky, Michael wrote:

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.

In R3.13 the TIMEZONE variable is only used by the vxWorks time
conversion routines such as ctime(), localtime() and their re-entrant
_r() versions. EPICS code doesn't use these, but some other programs
may. I wasn't aware of the above setting in drvTS.c, thanks for
pointing that out.
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're adding a base_patch support application to all our R3.13.10 IOCs
that contains an updated version of src/libCom/tsSubr.c and builds an
updated version of the libCom and iocCore binaries. While it looks like
this should also be building a new version of dbLib with an updated
drvTS.c, we haven't noticed anything strange here in the last few years
and the particular setting for TIMEZONE that you show above actually
dates back to about 2001, so I'm assuming that nothing we run uses the
OS routines anyway.
In case anyone else wants to use our base_patch code, I've made a tar
file available in the EPICS Base download area. There is a README file
with APS-specific installation instructions in it; adjust to your own
filesystem layout as necessary. This is version 1.2 of the base_patch
application because we had to make a similar kind of patch to R3.13.6.
The idea behind the base_patch is that you don't have to rebuild base to
fix the problem, just add this support application to the IOC's
config/RELEASE file and config/RULES.Vx and rebuild the IOC app.
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?

If your CA clients have been built with the R3.14 base libraries then
they rely on the native operating system code of the OS they're running
on, so you merely have to ensure you're up to date with your OS patches
on the machine the clients are running on. As you point out, that's
because the EPICS timestamps that pass over the network are encoded in UTC.
- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System