diff options
| author | Edward Welbourne <edward.welbourne@qt.io> | 2021-04-23 16:15:15 +0200 |
|---|---|---|
| committer | Edward Welbourne <edward.welbourne@qt.io> | 2021-04-27 14:12:35 +0200 |
| commit | 2383e82bcfcb9ef1e81eac3a4810b3860ea3cfb9 (patch) | |
| tree | 7cbdba2ee8ce15e859702193408f2ef5283bc512 /tests | |
| parent | 678cbaebcf212d24c23bb31bb6643cb57053b2de (diff) | |
Correct the parsing of POSIX rule day-of-year fields
There are two formats for such fields: one with a J prefix on a number
in the range 1 to 365, the other with no prefix and a range from 0 to
365. The code mistakenly treated the latter as if its range were from
1 to 366. The J-form doesn't count Feb 29th, so March always starts on
day 60; the code tried to take that into account, but adjusted in the
wrong direction (and this mislead me, in a recent partial fix, into a
fence-post error).
Add a test-case based on the Africa/Casablanca POSIX rule seen on RHEL
8.2, which tripped over the off-by-one error without a J prefix. This
incidentally also tests the J case.
Change-Id: I692ca511e5c960f91a6c21073d3b2f037f5e445f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'tests')
| -rw-r--r-- | tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp b/tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp index 2e197cca4a..19b638cce7 100644 --- a/tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp +++ b/tests/auto/corelib/time/qtimezone/tst_qtimezone.cpp @@ -1141,6 +1141,18 @@ void tst_QTimeZone::tzTest() QTzTimeZonePrivate tzposix("MET-1METDST-2,M3.5.0/02:00:00,M10.5.0/03:00:00"); QVERIFY(tzposix.isValid()); + // RHEL has been seen with this as Africa/Casablanca's POSIX rule: + QTzTimeZonePrivate permaDst("<+00>0<+01>,0/0,J365/25"); + const QTimeZone utcP1("UTC+01:00"); // Should always have same offset as permaDst + QVERIFY(permaDst.isValid()); + QVERIFY(permaDst.hasDaylightTime()); + QVERIFY(permaDst.isDaylightTime(QDate(2020, 1, 1).startOfDay(utcP1).toMSecsSinceEpoch())); + QVERIFY(permaDst.isDaylightTime(QDate(2020, 12, 31).endOfDay(utcP1).toMSecsSinceEpoch())); + // Note that the final /25 could be misunderstood as putting a fall-back at + // 1am on the next year's Jan 1st; check we don't do that: + QVERIFY(permaDst.isDaylightTime( + QDateTime(QDate(2020, 1, 1), QTime(1, 30), utcP1).toMSecsSinceEpoch())); + QTimeZone tzBrazil("BRT+3"); // parts of Northern Brazil, as a POSIX rule QVERIFY(tzBrazil.isValid()); QCOMPARE(tzBrazil.offsetFromUtc(QDateTime(QDate(1111, 11, 11).startOfDay())), -10800); |