Page MenuHome GnuPG

gpgme test suite fails when local time differs from UTC time across a day boundary.
Closed, ResolvedPublic

Description

My local date is different from the UTC date right now (i'm in -0400, so this is true only 4 hours out of the day). If i run the gpgme test suite in my local TZ, i see:

********* Start testing of TestVarious *********
Config: Using QtTest library 5.15.2, Qt 5.15.2 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.2.0), debian unknown
PASS   : TestVarious::initTestCase()
PASS   : TestVarious::testDN()
PASS   : TestVarious::testKeyFromFile()
PASS   : TestVarious::testDataRewind()
PASS   : TestVarious::testQuickUid()
PASS   : TestVarious::testSetExpire()
PASS   : TestVarious::testSignKeyWithoutExpiration()
FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/05
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [../../../../lang/qt/tests/t-various.cpp(342)]
PASS   : TestVarious::testVersion()
PASS   : TestVarious::cleanupTestCase()
Totals: 9 passed, 1 failed, 0 skipped, 0 blacklisted, 6337ms

If i run it under TZ=UTC, i see the tests all pass.

Details

Version
1.17.1

Event Timeline

Thanks. The solution should thus be easy.

I see the patch which does look like it will guarantee that the test suite succeeds. But does it solve the underlying problem, though? I worry that it might just paper over a more subtle problem.

Presumably the test suite was written using code that external developers are likely to use to check expiration dates in other software, and that software will not be run in TZ=UTC. Is there any risk that there's an underlying bug in the gpgme library, or the engine used, or in the test suite code itself that doesn't handle timezones correctly?

If the bug is just in the test suite code, it'd still be worth fixing that to run correctly independent of the external TZ so that people looking to learn how to use the library from the test suite aren't led astray.

ikloecker triaged this task as Normal priority.
ikloecker added a subscriber: ikloecker.

Having written the code and the test I'm with dkg here. The code takes the expiration date, calculates the number of days from today and tells gpg to set the expiration to <number of days>d. The idea of the aforementioned is that it should work for any timezone. Maybe this assumption is wrong.

ikloecker added a project: Restricted Project.Thu, Jun 9, 4:38 PM
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

I couldn't reproduce the one-off problem of the original report, but running the test with time zone UTC-11

TZ='Pacific/Pago_Pago' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

resulted in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2022/06/09
   Expected (QDate(2106, 2, 6)): 2106/02/06
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because adding 30557d (number of days in UTC-11 until 2106-02-06) to the current time resulted in a u32-overflow. I'll change the maximal expiration date to 2106-02-05 to avoid the overflow.

I don't really understand the original problem. Apparently, the code calculates one day less than expected. Hmm, could this somehow be related to daylight saving?

Yeah, seems to be related to daylight saving. Running

TZ='America/Adak' GPGME_DEBUG=3 TESTS="initial.test t-various" make -e check-TESTS

results in

FAIL!  : TestVarious::testSignKeyWithExpiration() Compared values are not the same
   Actual   (expirationDate)   : 2106/02/04
   Expected (QDate(2106, 2, 5)): 2106/02/05
   Loc: [/home/ingo/dev/g10/src/gpgme/lang/qt/tests/t-various.cpp(342)]

because the code adds 30555 days to the current time (2022-06-10-00:xx:xx+UTC-9) which gives us 2106-02-04-23:xx:xx+UTC-10.

I will change the test to accept the dates 2106/02/05 and 2106/02/04 as correct results.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

Fixed. Thanks for the report.