[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.