Hi Ralph,
Ralph Lange wrote:
I think I found something that smells like a bug in the vxWorks "local"
clock (or in libCom/osi/os/vxWorks/iocClock).
This smells like a similar issue to the SNS daylight savings problem.
Please try setting the EPICS_TIMEZONE environment variable instead of
the TIMEZONE variable from the st.cmd script and see if the same
behaviour occurs - Dave Thompson found that this made a difference, such
that before iocInit() you must use EPICS_TIMEZONE, not TIMEZONE.
If I've understood that problem properly it stems from the fact that
ANSI C doesn't provide a version of mktime() that takes in UTC, and the
vxWorks version of mktime() is broken. I started working on a new
epicsTimeLoadTimeInit::epicsTimeLoadTimeInit() routine in epicsTime.cpp
(Dave's problem seemed to be associated with the code that calculates
the values of epicsEpochOffset and epicsEpochOffsetAsAnUnsignedLong),
but haven't finished it yet.
- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey
- References:
- Bug in IOC "local" time Ralph Lange
- Navigate by Date:
- Prev:
Bug in IOC "local" time Ralph Lange
- Next:
Core-talk moves to Mailman Andrew Johnson
- Index:
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:
Bug in IOC "local" time Ralph Lange
- Next:
Core-talk moves to Mailman Andrew Johnson
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|