There's no way to say "there is no daylight savings time this year"... it's hardcoded
into the UTC<->local conversions. But that only affects "local time" on the IOC, which
matters to e.g. timestamp records in the DB (which PEPII does use, for fault times for
instance).
Mike
-----Original Message-----
From: Chestnut, Ronald P. [mailto:[email protected]]
Sent: Monday, March 05, 2007 10:14 AM
To: Andrew Johnson
Cc: [email protected]
Subject: RE: 3.13.6 daylight-savings follies
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
- References:
- 3.13.6 daylight-savings follies Laznovsky, Michael
- Re: 3.13.6 daylight-savings follies Andrew Johnson
- RE: 3.13.6 daylight-savings follies Chestnut, Ronald P.
- Navigate by Date:
- Prev:
RE: 3.13.6 daylight-savings follies Chestnut, Ronald P.
- Next:
Re: 3.13.6 daylight-savings follies Andrew Johnson
- 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: 3.13.6 daylight-savings follies Chestnut, Ronald P.
- Next:
Re: 3.13.6 daylight-savings follies Andrew Johnson
- 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
|