taskwarrior fails in 2038

[bmwiedemann]

To report a bug...

• What command(s) did you run?
• • I had the system clock set to 2038-02-01 (e.g. use date --set=2038-02-01) and ran the python-tasklib testsuite. It did mkdir -p tmp31i4msvg ; echo -ne "[description:\"test task\" entry:\"2148595662\" modified:\"2148595662\" status:\"pending\" uuid:\"9df44f1e-3145-47cf-8b48-3c23cc625dd1\"]\n" > ./tmp31i4msvg/pending.data ; task "rc.confirmation=no" "rc.dependency.confirmation=no" "rc.recurrence.confirmation=no" "rc.json.array=off" "rc.bulk=0" "rc.data.location=./tmp31i4msvg" "9df44f1e-3145-47cf-8b48-3c23cc625dd1" "annotate" "test annotation"
• What did you expect to happen?
• • it should work similar to dates before 2038
• What actually happened?
• • Failed with '-2146371571' is not a valid date in the '' format.
• • The timestamps in the pending.data file are parsed correctly and the system time seems to be the problematic element.
• Paste the output of the task diag command.

> task diag
      
task 2.6.2
   Platform: Linux

Compiler
    Version: 12.1.1 20220812 [revision 6b7d570a5001bb79e34c0d1626a8c7f55386dac7]
       Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64
 Compliance: C++17

Build Features
      CMake: 3.24.1
    libuuid: libuuid + uuid_unparse_lower
  libgnutls: 3.7.7
 Build type: RelWithDebInfo
             
Configuration
       File: /home/abuild/.taskrc (found), 1375 bytes, mode 100644
       Data: ./tmp31i4msvg (found), dir, mode 40755           
    Locking: Enabled
         GC: Enabled
     Server:
         CA: -
Certificate: -
        Key: -
      Trust: strict
    Ciphers: NORMAL
      Creds:

Hooks
     System: Enabled
   Location: ./tmp31i4msvg/hooks
             (-none-)
             
Tests
   Terminal: 0x0
       Dups: Scanned 1 tasks for duplicate UUIDs:
             No duplicates found
 Broken ref: Scanned 1 tasks for broken references:
             No broken references found

Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future.
The usual offset is +16 years, because that is how long I expect some software will be used in some places.
This showed up failing tests in our python-tasklib package build.
See https://reproducible-builds.org/ for why this matters.

[bmwiedemann]

I got a backtrace:

(gdb) b Datetime.cpp:92
(gdb) r
Breakpoint 1, Datetime::Datetime (this=0x7fffffffc420, input=..., format=...) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/libshared/src/Datetime.cpp:92
92          throw ::format ("'{1}' is not a valid date in the '{2}' format.", input, format);

(gdb) bt
#0  Datetime::Datetime (this=0x7fffffffc420, input=..., format=...) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/libshared/src/Datetime.cpp:92
#1  0x0000555555584778 in Task::composeJSON[abi:cxx11](bool) const (this=0x5555559e4c30, decorate=false) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/Task.cpp:1065
#2  0x0000555555571675 in TDB2::update (this=0x7fffffffdb28, task=..., add_to_backlog=true, addition=false) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/TDB2.cpp:725
#3  0x0000555555570e2a in TDB2::modify (this=0x7fffffffdb28, task=..., add_to_backlog=true) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/TDB2.cpp:655
#4  0x00005555555d7d03 in CmdAnnotate::execute (this=0x5555559c6450) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/commands/CmdAnnotate.cpp:89
#5  0x00005555555407ab in Context::dispatch (this=0x7fffffffd8c0, out=...) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/Context.cpp:886
#6  0x000055555553f840 in Context::run (this=0x7fffffffd8c0) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/Context.cpp:736
#7  0x0000555555539b4b in main (argc=10, argv=0x7fffffffe4f8) at /usr/src/debug/taskwarrior-2.6.2-0.x86_64/src/main.cpp:53

(gdb) p i.first
$4 = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, 
    _M_p = 0x555555982730 "annotation_-2146368945"}, _M_string_length = 22, {_M_local_buf = "\026", '\000' <repeats 14 times>, _M_allocated_capacity = 22}}

[bmwiedemann]

I found a nice fix. #3052 has a 2nd commit with more fixes that are not strictly needed to solve this issue.