Re: [Development] How does mktime() handle DST transitions ?

[Welbourne Edward]

Hi again Mandeep,

Thanks for that.

> Accepted: 1446367200
> Ignorant of DST (-> 1): Sun Nov  1 01:40:00 2015
> Accepted: 1446370860
> Ignorant of DST (-> 0): Sun Nov  1 01:41:00 2015

OK, fun - now I know when at least one implementation changes over within the 
hour !

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Mandeep Sandhu]

Awesome! Glad I could help.

-mandeep



On Tue, Nov 17, 2015 at 5:40 AM, Welbourne Edward
 wrote:
> Hi again Mandeep,
>
> Thanks for that.
>
>> Accepted: 1446367200
>> Ignorant of DST (-> 1): Sun Nov  1 01:40:00 2015
>> Accepted: 1446370860
>> Ignorant of DST (-> 0): Sun Nov  1 01:41:00 2015
>
> OK, fun - now I know when at least one implementation changes over within the 
> hour !
>
> Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Mandeep Sandhu]

Hey Eddy,

Here's the response from my OSX 10.10.4 (Time Zone: Pacific Standard
Time (PST) -0800 UTC UTC/GMT).

$ ./mktime
Studying DST transitions in system default time-zone

Testing spring forward
Initial: Sun Mar  8 02:30:00 2015

Accepted: 1425810600
Ignorant of DST (-> 1): Sun Mar  8 03:30:00 2015
Accepted: 1425810600
Claiming no DST (-> 1): Sun Mar  8 03:30:00 2015

Accepted: 1425807000
Claiming DST (-> 0): Sun Mar  8 01:30:00 2015


Testing fall backward
Initial: Sun Nov  1 01:30:00 2015

Accepted: 1446366600
Ignorant of DST (-> 1): Sun Nov  1 01:30:00 2015
Accepted: 1446367200
Ignorant of DST (-> 1): Sun Nov  1 01:40:00 2015
Accepted: 1446370860
Ignorant of DST (-> 0): Sun Nov  1 01:41:00 2015
Accepted: 1446370200
Claiming no DST (-> 0): Sun Nov  1 01:30:00 2015

Accepted: 1446366600
Claiming DST (-> 1): Sun Nov  1 01:30:00 2015

$

HTH,
-mandeep




On Fri, Nov 6, 2015 at 4:34 AM, Welbourne Edward
 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
>
> MinGW
> 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).
>
> Eddy
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Welbourne Edward]

> 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

MinGW
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).

Eddy/* Report on current Time-Zone's DST transitions, if any. */
#include 
#include 
#include 

static const struct tm summer = { 0,0,0, 21, 5,115, 0 };
static const struct tm winter = { 0,0,0, 21,11,115, 0 };

/* Half-way between two struct tm, ignoring their .tm_isdst: */
static struct tm centre(struct tm lo, struct tm hi) {
/* Round up, as lo is typically hh:59:59 */
lo.tm_sec = (lo.tm_sec + hi.tm_sec + 1) / 2;

lo.tm_min = lo.tm_min + hi.tm_min;
if (lo.tm_min % 2)
lo.tm_sec += 30;
lo.tm_min /= 2;

while (lo.tm_sec >= 60) {
lo.tm_sec -= 60;
lo.tm_min += 1;
}

lo.tm_min += 30 * (hi.tm_hour - lo.tm_hour);
while (lo.tm_min > 60) {
lo.tm_min -= 60;
lo.tm_hour += 1;
}
/* Axiom: same day, so lo.tm_hour <= hi.tm_hour < 24 still. */
return lo;
}

/* Find the transitions, if any. */
static int hasDST(struct tm *spring, struct tm *autumn) {
struct tm *output[2] = { spring, autumn };
struct tm dst = summer; /* When we might have daylight-saving time */
struct tm std = winter; /* When we definitely have standard time */
std.tm_year -= 1; /* bracket the first half of 2015 */
dst.tm_isdst = std.tm_isdst = -1;

time_t tdst = mktime(), tstd = mktime();
if (dst.tm_isdst == std.tm_isdst) return 0; /* No transition */
int south = std.tm_isdst; /* Southern hemisphere */
if (south) { /* Swap dst<->std, tdst<->tstd */
tdst ^= tstd; tstd ^= tdst; tdst ^= tstd;
dst = std;
std = summer; /* misnamed: June is winter */
}
for (int i = 0; i < 2; i++) {
if (i) { /* bracket the second half of 2015 */
if (south) {
std = summer;
dst = winter;
} else {
std = winter;
dst = summer;
}
tstd = mktime();
tdst = mktime();
if (std.tm_isdst || !dst.tm_isdst) {
fputs("DST-ness changed this year !\n", stderr);
exit(1);
}
} /* else: initialization taken care of before loop. */

struct tm mid, *cut;
time_t mean = (tdst + tstd) / 2;
while (mean != tdst && mean != tstd &&
   0 != (cut = localtime())) {
mid = *cut;
if (mid.tm_isdst == -1) {
fprintf(stderr, "Indeterminate DST-ness after localtime(%s)\n",
asctime());
exit(1);
} else if (mid.tm_isdst) {
dst = mid;
tdst = mean;
} else {
std = mid;
tstd = mean;
}
/* Compute new mean */
mean = (tdst + tstd) / 2;
}
if (cut == 0) {
perror("Failed localtime");
fprintf(stderr, "at t = %ld\n", (long)mean);
exit(1);
}

/* Post-process to get middle of the transition: */
if (std.tm_isdst || !dst.tm_isdst)
fputs("Failed chop :-(\n", stderr);
else if (std.tm_mday != dst.tm_mday ||
 std.tm_year != dst.tm_year || std.tm_mon != dst.tm_mon ||
 std.tm_wday != dst.tm_wday || std.tm_yday != dst.tm_yday)
fprintf(stderr,
"DST transition straddles day; 

Re: [Development] How does mktime() handle DST transitions ?

[John Layt]

On 3 November 2015 at 14:28, Welbourne Edward <
edward.welbou...@theqtcompany.com> wrote:

> Hi all,
>
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the other end there's
> a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
> Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
> out what behaviour *we* want to give, implementing it is going to depend
> on knowing what the platform mktime gives us to work with.
>
> I know glibc's behaviour (2.19-22), although confirmation of it from
> elsewhere and version variation may be worth knowing.  We have a kludge
> for MS-Win that suggests what it does (actually quite sensible, though
> different to GNU), but I'd be glad of confirmation.  The 'net suggests
> FreeBSD may even treat some of it as errors; I may need to follow up on
> that, and on Mac.  So I wrote a simple test program.
>
> 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.  Those not in Europe
> shall need to amend the data in two statics at the top of the file
> (there are comments to guide you) to hit when your DST transitions are.
> (I'd also be glad to know what those are, if you include a diff.)
>
> Eddy.
>

Hi Eddy,

I'm the original author of a lot of the current QDateTime/QTimeZone code,
thanks for looking into this, I'm sadly not in a position these days to
give much time to Qt.

There's a serious problem with mktime() and ambiguous hours, i.e. the hour
that gets repeated at daylight savings changeover. The root of the problem
is that the C/POSIX spec doesn't define the correct behaviour, so every
implementation decides what to do. I've previously documented the exact
details in a previous email to the list a few years back which I can dig up
if needed, but here's what I recall. On Windows they default to the second
occurrence of the time. On Mac/BSD they default to the first occurrence,
except on some versions where the first 43 or so minutes are the first
occurrence and the rest are second occurrence! On GNU it just uses whatever
the last time calculation had cached as the occurrence, or the first
occurrence if nothing is cached, so is completely unreliable! On Windows
mktime() in general use can also return different results than the higher
level Win32 api.  I concluded that we cannot reliably use mktime() for the
ambiguous time conversions, or even in general cross-platform use. My
conclusion was we needed to improve QTimeZone to be fast enough to replace
mktime() if we wanted 100% reliable and compatible behaviour across all
platforms. That may all have changed now we have more recent minimum
versions of each OS. As a rule, I favour going with a default of assuming
first occurrence, I think I found it easier to calculate from the tz
database rules and slightly more logical.  I've even got patches floating
around trying different ways of implementing a clean API to control this
based on the KDE api.

I'll try have a look at the bug on the weekend, but I can't promise
anything.

John.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Marc Mutz]

On Thursday 05 November 2015 14:54:04 André Somers wrote:
> Interesting, I did not know that the summertime adjustment is 
> synchronized in the EU. Interesting little factoid :-)

The sole purpose of this being, of course, to prevent you from speeding with 
your car without penalty for more than just one hour, just by crossing into an 
adjacent TZ...

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[André Somers]

Op 5-11-2015 om 00:06 schreef Kevin Kofler:

Welbourne Edward wrote:

I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
out what behaviour *we* want to give, implementing it is going to depend
on knowing what the platform mktime gives us to work with.

The EU actually defines the switchover time in UTC, so which hour is
duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST.

 
Nonsense*. I live in the CET (Netherlands), I am 100% sure that the hour 
duplicated is the 2:mm range, not the 3:mm range. At 03:00, the time is 
reset to 02:00 entering winter time again. That happened last October 
25. Going to summer time, the hour skipped is the 2:mm range also.


André

*) At least in so far the actual clock time in the country is concerned. 
Perhaps for other purposes the EU defines a single switchover moment for 
the whole of the EU? That is pure speculation though.



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Welbourne Edward]

Hi John,

I was hoping to hear from you - thanks for getting in touch.

> I'm the original author of a lot of the current QDateTime/QTimeZone code,

Indeed; git blame told me this and you'd shown up in my googling for
references to the topic, which is why I've added you to some
code-reviews.

> I'm sadly not in a position these days to give much time to Qt.

Fair enough.  Any help you can give is, of course, welcome.

> There's a serious problem with mktime() and ambiguous hours

Indeed.  Fortunately, this isn't the first time I've met it.
If I were dictator of the world, DST would be abolished right away !

> The root of the problem is that the C/POSIX spec doesn't
> define the correct behaviour,

Indeed, although part of the problem is that it's not entirely clear
what correct behaviour would be, regardless of spec.  The python answer
currently appeals to me - see links on the bug, when you find time.

> I've previously documented the exact details in a previous
> email to the list a few years back

I may have found that, although I thought it was a blog post (mail
archive software can confuse me that way).  See links on bug.

> On GNU it just uses whatever the last time calculation
> had cached as the occurrence,

Is that the .is_dst = -1 handling ?  At least for the 0 or 1 handling,
its behaviour is fairly straightforward - in the autumn overlap, it
preserves the .is_dst, in the spring gap it flips the .is_dst and
changes the hour in the way that matches that.  For the limited
testing I've done, the .is_dst = -1 has been to treat each the way
it does when opting to set .is_dst (or leave it set, in autumn).

Do you know what FreeBSD does ?  I read some old posts that appeared to
indicate it treated .is_dst = -1 as an error in the overlap and anything
in the gap as an error.  The FreeBSD maintainer appeared, back in 2000,
to firmly believe this was The Right Thing To Do; and my understanding
is that it's an entirely legitimate thing to do (wrt mktime's spec).  I
don't know if that's changed in the last fifteen years, though.

> On Windows mktime() in general use can also return different
> results than the higher level Win32 api.

Do you remember whether the high-level one was any more helpful,
sensible or predictable ?

> I concluded that we cannot reliably use mktime() for the
> ambiguous time conversions

My main problem with it is *detecting* when we're in a transition; if we
can do that, we can make up any rule we like and adjust suitably.  I
don't want the other > 99.96% of all hours to suffer any overhead,
of course, which is what makes detection tricky.

> or even in general cross-platform use.

I'm reasonably confident I can work round the portability issues, as
long as I have a reasonably good grasp of the kinds of variation that's
out there.  It helps that all cases for which I have reports so far -
OSX, glibc, MS-Win - agree on what to do when .is_dst is either 0 or 1.
The only variation at present is for .is_dst = -1.

> My conclusion was we needed to improve QTimeZone to be fast enough to
> replace mktime() if we wanted 100% reliable and compatible behaviour
> across all platforms.

OK, I guess I'd better take a close look at QTimeZone, then ;-)

> As a rule, I favour going with a default of assuming first occurrence,
> I think I found it easier to calculate from the tz database rules and
> slightly more logical.

That's reasonable for the (invalid) spring gap; but for the autumn
overlap there are genuinely two distinct times and we really should have
some way to represent them as distinct QDateTime objects.  I presently
rather like how python has resolved this.  (Again, see links on bug.)

> I've even got patches floating around trying different ways of
> implementing a clean API to control this based on the KDE api.

What is the KDE API ?  Point me at a link if you can, or post one on the
bug; I'd like to see what solutions have been tried, especially when I
can get some insight into how well they've worked out.  Naturally, I'd
also like to make sure whatever we come up with is easy for KDE to use,
too.

> I'll try have a look at the bug on the weekend, but I can't promise anything.

I quite understand - thanks for whatever time you can spare.
I'm afraid my notes on the bug aren't terse !

   Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Welbourne Edward]

Kevin Kofler wrote:
> The EU actually defines the switchover time in UTC,

That's a surprise.  Do you have a reference for that ?

> so which hour is duplicated depends on the actual
> time zone. It's the 3:mm hour in CET/CEST.

I distinctly remember, the weekend before last, seeing the 2:mm hour
duplicated, here in Oslo on CEST/CET.  That's also the hour I'm used to
being duplicated in the UK on BST/GMT, albeit I've been away for long
enough they could have changed it without me noticing.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Florian Bruhin]

* André Somers  [2015-11-05 13:10:33 +0100]:
> Op 5-11-2015 om 00:06 schreef Kevin Kofler:
> >Welbourne Edward wrote:
> >>I'm looking into QTBUG-49008 and need to work out how diverse
> >>implementations of mktime handle DST transitions: at one end of the year
> >>there's a gap (where 1:59 is followed by 3:00), at the other end there's
> >>a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
> >>Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
> >>out what behaviour *we* want to give, implementing it is going to depend
> >>on knowing what the platform mktime gives us to work with.
> >The EU actually defines the switchover time in UTC, so which hour is
> >duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST.
> >
> Nonsense*. I live in the CET (Netherlands), I am 100% sure that the hour
> duplicated is the 2:mm range, not the 3:mm range. At 03:00, the time is
> reset to 02:00 entering winter time again. That happened last October 25.
> Going to summer time, the hour skipped is the 2:mm range also.

While not in the EU, I can confirm what André said for Switzerland as
well :)

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


signature.asc
Description: Digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Kevin Kofler]

André Somers wrote:
> Actually, you are right about the sync in the EU (for all clocks) and
> about the hour that is duplicated depending on the time zone, but I
> think you are off on the hour it happens. In CET it is 2:mm that is
> duplicated, in GMT and WET it is 1:mm and in finland (EET) it is 3:mm
> that is duplicated.
> 
> See
> http://www.timeanddate.com/news/time/europe-dst-end-2015.html

You're of course right.

Sorry, I should have remembered the exact time, being up at that time more 
often than not and also having to deal with it in programming at times. 
Looks like I was just too tired when I wrote this.

> Interesting, I did not know that the summertime adjustment is
> synchronized in the EU. Interesting little factoid :-)

Yes, and I felt it important to point this out, which is why I rushed to 
reply (and then screwed it up).

Sorry for the misinformation,
Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Thiago Macieira]

On Thursday 05 November 2015 13:10:33 André Somers wrote:
> *) At least in so far the actual clock time in the country is concerned. 
> Perhaps for other purposes the EU defines a single switchover moment for 
> the whole of the EU? That is pure speculation though.

Correct. In Finland, the clocks go back at 4:00 back to 3:00.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Thiago Macieira]

On Thursday 05 November 2015 08:45:01 Thiago Macieira wrote:
> On Thursday 05 November 2015 13:10:33 André Somers wrote:
> > *) At least in so far the actual clock time in the country is concerned.
> > Perhaps for other purposes the EU defines a single switchover moment for
> > the whole of the EU? That is pure speculation though.
> 
> Correct. In Finland, the clocks go back at 4:00 back to 3:00.

And in Portugal, at 2:00 they go back to 1:00.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[André Somers]

Op 5-11-2015 om 00:06 schreef Kevin Kofler:

Welbourne Edward wrote:

I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
out what behaviour *we* want to give, implementing it is going to depend
on knowing what the platform mktime gives us to work with.

The EU actually defines the switchover time in UTC, so which hour is
duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST.


Actually, you are right about the sync in the EU (for all clocks) and 
about the hour that is duplicated depending on the time zone, but I 
think you are off on the hour it happens. In CET it is 2:mm that is 
duplicated, in GMT and WET it is 1:mm and in finland (EET) it is 3:mm 
that is duplicated.


See
http://www.timeanddate.com/news/time/europe-dst-end-2015.html

Interesting, I did not know that the summertime adjustment is 
synchronized in the EU. Interesting little factoid :-)


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How does mktime() handle DST transitions ?

[Kevin Kofler]

Welbourne Edward wrote:
> I'm looking into QTBUG-49008 and need to work out how diverse
> implementations of mktime handle DST transitions: at one end of the year
> there's a gap (where 1:59 is followed by 3:00), at the other end there's
> a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
> Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
> out what behaviour *we* want to give, implementing it is going to depend
> on knowing what the platform mktime gives us to work with.

The EU actually defines the switchover time in UTC, so which hour is 
duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] How does mktime() handle DST transitions ?

[Welbourne Edward]

Hi all,

I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
Europe, or 1:59 by 1:00 in the USA, IIUC).  While we still need to work
out what behaviour *we* want to give, implementing it is going to depend
on knowing what the platform mktime gives us to work with.

I know glibc's behaviour (2.19-22), although confirmation of it from
elsewhere and version variation may be worth knowing.  We have a kludge
for MS-Win that suggests what it does (actually quite sensible, though
different to GNU), but I'd be glad of confirmation.  The 'net suggests
FreeBSD may even treat some of it as errors; I may need to follow up on
that, and on Mac.  So I wrote a simple test program.

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.  Those not in Europe
shall need to amend the data in two statics at the top of the file
(there are comments to guide you) to hit when your DST transitions are.
(I'd also be glad to know what those are, if you include a diff.)

Eddy.
#include 
#include 

/* Europe switches between a Sunday's 2 and 3 am in March and October.
 * If you're elsewhere, please look up your local details and amend these two
 * statics appropriately.  Years are off by 1900 (2015 is 115), months are off
 * by 1 (Jan = 0, Dec = 11).  */
static const struct tm spring = {
0, 30, /* half past the hour */
2, /* the hour that gets skipped */
29, 2, 115, /* 2015-03-29; a Sunday */
0 /* static: 0-fill all remaining fields */
};
static const struct tm autumn = {
0, 30, /* half past the hour */
2, /* (1 in the USA) the hour that gets repeated */
25, 9, 115, /* 2015-10-25; a Sunday */
0 /* static: 0-fill all remaining fields */
};
/*  Pass -Wno-missing-field-initializers (or its equivalent) to
 * your compiler, if enabling warnings; ANSI C '89 specified that all
 * unspecified fields of a static get 0-filled. */

static void report(time_t got) {
if (got == (time_t) -1) puts("Rejected.");
else printf("Accepted: %ld\n", (long) got);
}

static void study(const struct tm *when) {
char datebuffer[52]; /* twice what asctime_r() asks for */
struct tm test = *when;
printf("Initial: %s\n", asctime_r(, datebuffer));

test.tm_isdst = -1;
report(mktime());
printf("Ignorant of DST (-> %d): %s", test.tm_isdst, asctime_r(, datebuffer));
puts(""); /* Blank line */

test = *when;
test.tm_isdst = 0;
report(mktime());
printf("Claiming no DST (-> %d): %s", test.tm_isdst, asctime_r(, datebuffer));
puts(""); /* Blank line */

test = *when;
test.tm_isdst = 1;
report(mktime());
printf("Claiming DST (-> %d): %s", test.tm_isdst, asctime_r(, datebuffer));
}

int main(void) {
tzset(); /* Just to be entirely sure it *does* get called. */
puts("Testing spring forward");
study();
puts("\n\nTesting fall backward");
study();
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development