EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <2007>  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <2007>  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Daylight saving time
From: Andrew Johnson <[email protected]>
To: EPICS tech-talk <[email protected]>
Date: Thu, 25 Jan 2007 10:52:27 -0600
Ernest Williams just pointed out that most US EPICS sites will have a larger-than-normal problem with the local time changes on their vxWorks IOCs this year:

> *2007 - THE YEAR DAYLIGHT SAVING TIME GAINED GROUND*
>
> Thanks to the 2005 Energy Policy Act, most of the U.S. will begin
> Daylight Saving Time (DST) this year at 2:00 a.m. on the second
> Sunday in March (March 11) and revert to standard time on the first
> Sunday in November (November 4).

http://www.imakenews.com/symmntp/e_article000736824.cfm?x=b8Rvtjm,b20DVrBy

R3.14 on vxWorks uses an environment variable whose default value is set in the configure/CONFIG_SITE_ENV file to tell vxWorks the month, day and hour of the start and end of DST:
EPICS_TIMEZONE=CUS::360:031102:110402
The R3.14.9 release will have the above setting which is correct for 2007 (thanks to Ralph Lange who keeps on top of this for us), but all older releases will probably have older settings such as:
EPICS_TIMEZONE=CUS::360:040202:102902
EPICS_TIMEZONE=CUS::360:040402:103102

Unfortunately it's not possible to change when any R3.13 IOCs switch to/from DST without recompiling Base, since the old US rules are hard-coded into the tsStampToLocal() routine (in src/libCom/tsSubr.c).

This will only affect timestamps that get converted into local time on a vxWorks IOC, which is probably not many, but it still could cause confusion, especially since this year the DST start and end dates changed by more than they normally do (under the old US rules DST started on the first Sunday in April and ended on the last Sunday in October, so it's likely that few people noticed if their IOCs were wrong for the few days they were out of sync).

EPICS timestamps are related to UTC, and any that are fetched through Channel Access get converted to local time by the CA client, so even if the IOC has the wrong setting your archived data should not be affected.

On a vxWorks IOC running R3.14.x that you don't want to reboot, the fix should be to just execute the following command (yes, that is meant to be TIMEZONE, not EPICS_TIMEZONE):
putenv "TIMEZONE=CUS::360:031102:110402"

Whether and how you make that change in all your startup scripts or just rebuild base with a new CONFIG_SITE_ENV setting has to be up to each site to decide.

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey
Navigate by Date:
Prev: RE: MEDM Byte Monitor Object Paul Sichta
Next: diagnostics related to discarding an intermediate CA subscription update Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <2007>  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: MEDM Byte Monitor Object Paul Sichta
Next: diagnostics related to discarding an intermediate CA subscription update Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <2007>  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·