Experimental Physics and
Industrial Control System

"Chestnut, Ronald P." <[email protected]> · Mon, 5 Mar 2007 10:14:08 -0800

This sounds great! - now a question about some older applications ...

If we don't want to really fix the problem, but work around in the least invasive way, (for 3.13.2, for example), is it possible to set the TS_MIN_WEST string to one hour ahead (Denver instead of Palo Alto), AND set it to say "there is no daylight savings time this year". We could then simply reboot on March 11, and forget any problems until the November date where we switch back.

And another strange question - is it necessary at all to change the IOC times, if one is only interested in timestamps on PVs? It seems to be the case that IOCs return time stamps in GMT, and that clients on Unix do the conversions to local time.

Ron Chestnut

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]] 
Sent: Monday, March 05, 2007 8:44 AM
To: Laznovsky, Michael
Cc: [email protected]
Subject: Re: 3.13.6 daylight-savings follies

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