[Development] How does mktime() handle DST transitions ?
mandeepsandhu.chd at gmail.com
Mon Nov 16 19:50:46 CET 2015
Here's the response from my OSX 10.10.4 (Time Zone: Pacific Standard
Time (PST) -0800 UTC UTC/GMT).
Studying DST transitions in system default time-zone
Testing spring forward
Initial: Sun Mar 8 02:30:00 2015
Ignorant of DST (-> 1): Sun Mar 8 03:30:00 2015
Claiming no DST (-> 1): Sun Mar 8 03:30:00 2015
Claiming DST (-> 0): Sun Mar 8 01:30:00 2015
Testing fall backward
Initial: Sun Nov 1 01:30:00 2015
Ignorant of DST (-> 1): Sun Nov 1 01:30:00 2015
Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015
Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015
Claiming no DST (-> 0): Sun Nov 1 01:30:00 2015
Claiming DST (-> 1): Sun Nov 1 01:30:00 2015
On Fri, Nov 6, 2015 at 4:34 AM, Welbourne Edward
<edward.welbourne at theqtcompany.com> wrote:
>> If you're willing to compile and run the attached simple C program,
>> please let me know its output and your platform's details - ideally
>> off-list - I'll give a summary in a few days' time.
> Thanks to those who responded, I now know:
> * that all the platforms below do the same thing if tm_isdst is 0 or 1 (Yay !)
> * with .tm_isdst = -1, there is diversity of handling.
> When tm_isdst is 0 or 1, in the fall back it gets preserved;
> in the spring forward, it gets flipped and tm_hour is changed
> in the way it usually would for such a flip.
> OSX 10.10, Xcode 6.02
> * varies within the hour (see below)
> * at half past: handled as if you'd claimed tm_isdst = 0 (see above)
> MacBook, Darwin 15.0.0
> Ubuntu 12.04, glibc 2.15
> Debian/stretch, glibc 2.19
> * clear tm_isdst and move an hour earlier in spring
> * set tm_isdst and preserve hour in autumn
> MSVC 2015
> * set tm_isdst and move an hour later in spring
> * clear tm_isdst and preserve hour in autumn.
> My initial test was, it turns out, naive. Apparently some platforms
> vary handling of -1 across the hour. I also bit the bullet and worked
> out how to auto-detect DST transitions. One response indicates
> asctime_r() isn't portable. So I attach a new version of mktime.c, that
> needs no manual configuration and is, I hope, a little more portable. I
> note that setting the TZ environment variable (on platforms that honour
> it, at least) can be used to discover what your O/S thinks happens in
> other time-zones than your local one.
> As before, if anyone feels inclined to give this a whirl, I'd again
> appreciate any responses, along with descriptions of the system they
> come from (e.g. uname -a output).
> Development mailing list
> Development at qt-project.org
More information about the Development