Daylight saving time

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

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