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
