Thiago Macieira (26 mars 2017 8:12 PM) >> This test began failing today:
>> FAIL! : tst_QLocale::macDefaultLocale() >> 'timeString.contains(expectedGMTSpecifier) || >> timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. >> (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03') >> The expectation is correct, since Finland is now in Summer time at GMT+3. >> Someone on a Mac, please check why it's getting GMT+02. Rolland Dudemaine (27 March 2017 07:03) > Daylight savings are not done at midnight, but at 2am. See > https://en.m.wikipedia.org/wiki/Daylight_saving_time Well, 3am in fact. Hover [0]'s "DST started" box. [0] https://www.timeanddate.com/worldclock/finland/helsinki Not that it makes a difference here. > Seems like Mac is correct, and the test should not fail. Indeed, at 1:2:3 that morning, DST had not yet started. Why did the test expect +3 ? ... /me takes a look ... It uses current time and works out the DST offset at it. Then it builds locale.toString(QTime(1, 2, 3), QLocale::LongFormat) and expects that to have the same offset. This is the bug, in the test. I infer that it passes now and fails two Sundays (less a few hours) per year. If we changed it to use QTime(10, 9, 8) it would only fail for a few hours on each of those two Sundays. Or we could use QDateTime(today, QTime(1, 2, 3)) instead of current time to compute the offset. That would avoid any fails. Might I just take this moment to suggest someone review my many (many) changes to date-time and time-zone code, some of which have languished for more than a year ? I hadn't caught this one, but some of them fix this kind of "that one day (or two) each year it's a problem" bug. ... and those are bugs in the code, not the test, Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development