EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows
From: <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Mon, 19 Oct 2015 16:17:16 +0000
Hi Michael,

test results enclosed for running on windows-x64, _tzset() is indeed ignored by epicsTime_localtime() (or rather by GetTimeZoneInformation()) but should be honoured by the built-in localtime() function

Regards,

Freddie

> -----Original Message-----
> From: Michael Davidsaver [mailto:[email protected]]
> Sent: 19 October 2015 14:59
> To: Akeroyd, Freddie (STFC,RAL,ISIS); [email protected]
> Subject: Re: epicsTime_localtime() currently reports daylight saving time
> incorrectly on Windows
> 
> I've tried to create a test case for this.  Please run epicsTimeZoneTest in
> src/libCom/test and report the results.
> 
> git clone --branch tztest https://github.com/mdavidsaver/epics-base.git
> cd epics-base
> make -C src libCom/test
> ./src/libCom/test/O.*/epicsTimeZoneTest.exe
> 
> I've already found that _tzset() with WINE 1.6.2 doesn't seem to have any
> effect, so the tests fail.
> 
> On 10/19/2015 07:10 AM, [email protected] wrote:
> > Hi,
> >
> > I've noticed that the "tm_isdst" member of the "struct tm" returned by the
> Win32 implementation of epicsTime_localtime() is not currently reporting
> DST status correctly. The problem is that though the StandardDate /
> DaylightDate members of TIME_ZONE_INFORMATION are SYSTEMTIME
> structures, they have slightly different interpretations of their contents than
> usual in particular   wDay == 5  means "last occurrence of wDayOfWeek in
> the month" rather than "5th day of month". One solution would be to use the
> status returned by GetTimeZoneInformation() which now seems to include
> the DST status, but I think the epicsTime_localtime() implementation could
> actually be replace by something simpler like (give or take a NULL pointer
> check):
> >
> > 	    memcpy(pTM, localtime(pAnsiTime), sizeof(struct tm));
> >
> > as on WIN32 the localtime() function uses thread local storage rather than
> global static storage (though the same TLS is shared with gmtime() )
> >
> > Regards,
> >
> > Freddie
> >
> >
1..80
# POSIX 1445259616
# TZ="EST5EDT"
# test_localtime(1445259616, ...)
ok  1 - epicsTime_localtime() success
ok  2 - sec 16==16
ok  3 - min 0==0
not ok  4 - hour 14==9
ok  5 - mday 19==19
ok  6 - mon 9==9
ok  7 - year 2015==2015
ok  8 - wday 1==1
ok  9 - yday 291==291
not ok 10 - isdst 0==1
# TZ="CST6CDT"
# test_localtime(1445259616, ...)
ok 11 - epicsTime_localtime() success
ok 12 - sec 16==16
ok 13 - min 0==0
not ok 14 - hour 14==8
ok 15 - mday 19==19
ok 16 - mon 9==9
ok 17 - year 2015==2015
ok 18 - wday 1==1
ok 19 - yday 291==291
not ok 20 - isdst 0==1
# TZ="UTC"
# test_localtime(1445259616, ...)
ok 21 - epicsTime_localtime() success
ok 22 - sec 16==16
ok 23 - min 0==0
not ok 24 - hour 14==13
ok 25 - mday 19==19
ok 26 - mon 9==9
ok 27 - year 2015==2015
ok 28 - wday 1==1
ok 29 - yday 291==291
ok 30 - isdst 0==0
# test_gmtime(1445259616, ...)
ok 31 - epicsTime_localtime() success
ok 32 - sec 16==16
ok 33 - min 0==0
ok 34 - hour 13==13
ok 35 - mday 19==19
ok 36 - mon 9==9
ok 37 - year 2015==2015
ok 38 - wday 1==1
ok 39 - yday 291==291
ok 40 - isdst 0==0
# POSIX 1421244931
# TZ="EST5EDT"
# test_localtime(1421244931, ...)
ok 41 - epicsTime_localtime() success
ok 42 - sec 31==31
ok 43 - min 15==15
not ok 44 - hour 14==9
ok 45 - mday 14==14
ok 46 - mon 0==0
ok 47 - year 2015==2015
ok 48 - wday 3==3
ok 49 - yday 13==13
ok 50 - isdst 0==0
# TZ="CST6CDT"
# test_localtime(1421244931, ...)
ok 51 - epicsTime_localtime() success
ok 52 - sec 31==31
ok 53 - min 15==15
not ok 54 - hour 14==8
ok 55 - mday 14==14
ok 56 - mon 0==0
ok 57 - year 2015==2015
ok 58 - wday 3==3
ok 59 - yday 13==13
ok 60 - isdst 0==0
# TZ="UTC"
# test_localtime(1421244931, ...)
ok 61 - epicsTime_localtime() success
ok 62 - sec 31==31
ok 63 - min 15==15
ok 64 - hour 14==14
ok 65 - mday 14==14
ok 66 - mon 0==0
ok 67 - year 2015==2015
ok 68 - wday 3==3
ok 69 - yday 13==13
ok 70 - isdst 0==0
# test_gmtime(1421244931, ...)
ok 71 - epicsTime_localtime() success
ok 72 - sec 31==31
ok 73 - min 15==15
ok 74 - hour 14==14
ok 75 - mday 14==14
ok 76 - mon 0==0
ok 77 - year 2015==2015
ok 78 - wday 3==3
ok 79 - yday 13==13
ok 80 - isdst 0==0

    Results
    =======
       Tests: 80 
      Passed:  73 = 91.25%
      Failed:   7 =  8.75%

Replies:
Re: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows Michael Davidsaver
References:
epicsTime_localtime() currently reports daylight saving time incorrectly on Windows freddie.akeroyd
Re: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows Michael Davidsaver

Navigate by Date:
Prev: RE: asyn timeout Mark Rivers
Next: Re: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows Michael Davidsaver
Next: Re: epicsTime_localtime() currently reports daylight saving time incorrectly on Windows Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024