[Development] How does mktime() handle DST transitions ?
jlayt at kde.org
Thu Nov 5 09:40:01 CET 2015
On 3 November 2015 at 14:28, Welbourne Edward <
edward.welbourne at 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.)
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development