tests fail after 2038

[bmwiedemann]

Description

Bug description:

While working on reproducible builds for openSUSE, I found that our wxWidgets-3_2 (3.2.4) package fails tests when the system clock is set to the year 2038.

Expected vs observed behaviour:

test output looks thus:

 DateTimeTestCase
   TestTimeZoneParse
 -------------------------------------------------------------------------------
 ./datetime/datetimetest.cpp:223
 ...............................................................................
 
 ./datetime/datetimetest.cpp:1014: FAILED: 
   REQUIRE( 13 == dt.GetHour(wxDateTime::UTC) )
 with expansion:
   13 == 14
 
 tar: Malformed extended header: invalid atime=1.07814e+09
 tar: Malformed extended header: invalid ctime=2.21842e+09
 tar: Malformed extended header: invalid atime=1.07814e+09
 tar: Malformed extended header: invalid ctime=2.21842e+09
...
 test cases:     313 |     312 passed | 1 failed
 assertions: 1229575 | 1229574 passed | 1 failed

Tests should keep working in the future - at least 16 years would be good.

Stack trace:

N/A

To Reproduce:

on Debian or openSUSE do

osc checkout openSUSE:Factory/wxWidgets-3_2 && cd $_
osc build --noservice --vm-type=kvm --build-opt=--vm-custom-opt="-rtc base=2040-04-19T02:01:51" standard x86_64

Sometimes reproduction is not reliable - it might depend on the exact moment the test is run and how floating point values are rounded.

Platform and version information

• wxWidgets version you use: 3.2.4
• wxWidgets port you use: wxGTK
• OS and its version: openSUSE-Tumbleweed 20240313 (x64_64)

[vadz]

Thanks, I can reproduce this with faketime '2040-04-19T02:01:51' ./tests/test -c TestTimeZoneParse DateTimeTestCase and it's the very first test which fails, i.e. it misparses "09:37-0400" as 14:37 in UTC for some reason.

With

diff --git a/tests/datetime/datetimetest.cpp b/tests/datetime/datetimetest.cpp
index 565a1077cf..204ddd461c 100644
--- a/tests/datetime/datetimetest.cpp
+++ b/tests/datetime/datetimetest.cpp
@@ -1005,10 +1005,14 @@ void DateTimeTestCase::TestTimeZoneParse()
     {
         wxDateTime dt;
         wxString sTimeZone = wxString::FromUTF8(parseTestTimeZones[n].str);
+        INFO("Test #" << n << " using format \"" << sTimeZone << "\"");
+
         wxString::const_iterator end;
         if ( dt.ParseFormat(sTimeZone, wxS("%H:%M%z"), &end)
              && end == sTimeZone.end() )
         {
+            INFO("Parsed time: " << dt.FormatISOTime());
+
             CPPUNIT_ASSERT( parseTestTimeZones[n].good );
             CPPUNIT_ASSERT_EQUAL( 13, dt.GetHour(wxDateTime::UTC));
             CPPUNIT_ASSERT_EQUAL( 37, dt.GetMinute(wxDateTime::UTC));

I get

Test program for wxWidgets non-GUI features
build: 3.3.0 (wchar_t,compiler with C++ ABI compatible with gcc 4,STL containers,compatible with 3.2)
compiled using gcc 12.2
running under Linux 6.6.9-amd64 x86_64 as zeitlin
Filters: DateTimeTestCase

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test is a Catch v2.13.9 host application.
Run with -? for options

-------------------------------------------------------------------------------
DateTimeTestCase
  TestTimeZoneParse
-------------------------------------------------------------------------------
tests/datetime/datetimetest.cpp:223
...............................................................................

datetime/datetimetest.cpp:1017: FAILED:
  REQUIRE( 13 == dt.GetHour(wxDateTime::UTC) )
with expansion:
  13 == 14
with messages:
  Test #0 using format "09:37-0400"
  Parsed time: 14:37:00

===============================================================================
test cases: 1 | 1 failed
assertions: 2 | 1 passed | 1 failed

I don't have time to debug this now, unfortunately, but it definitely needs to be fixed, of course.

[bmwiedemann]

faketime '2038-03-14T00:00:00' is the earliest that triggers this

US DST rules say DST

begins at 2:00 a.m. on the second Sunday of March (at 2 a.m. the local time time skips ahead to 3 a.m. so there is one less hour in that day)
ends at 2:00 a.m. on the first Sunday of November

and dates after 2038-11-07 don't trigger the issue, so something goes wrong in the US-DST-code after 2038.

[vadz]

Yes, this is almost certainly DST-related, it's just that we need find out what exactly...

[MaartenBent]

It happens on Windows too. I think it is related to

wxWidgets/src/common/datetime.cpp

Line 1273 in 75c5528

static const int yearMaxInRange = 2037;

It uses a fall-back called JDN that doesn't seem to do anything with timezones?

The fix is probably to remove this yearMaxInRange constraint when time_t is 64-bits.

[vadz]

Right, thanks. We need to use the 2038 bound for 32 bit time_t only and, ideally, we should do something about the DST even in the else branch, e.g. assume that the rules are the same as for 2037 for it.