Re: 3.13.6 daylight-savings follies

[Andrew Johnson <anj@aps.anl.gov>]

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