Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

taskwarrior fails in 2038 #3050

Closed
bmwiedemann opened this issue Jan 18, 2023 · 2 comments
Closed

taskwarrior fails in 2038 #3050

bmwiedemann opened this issue Jan 18, 2023 · 2 comments

Comments

@bmwiedemann
Copy link
Contributor

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
Copy link
Contributor Author

bmwiedemann commented Jan 19, 2023 •
edited
Loading

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 added a commit to bmwiedemann/taskwarrior that referenced this issue Jan 19, 2023
@bmwiedemann
Fix annotations in year 2038
e7e71a3 
Fixes GothenburgBitFactory#3050
@bmwiedemann
Copy link
Contributor Author

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

bmwiedemann added a commit to bmwiedemann/taskwarrior that referenced this issue Aug 23, 2023
@bmwiedemann
Fix annotations in year 2038
19b88e8 
Fixes GothenburgBitFactory#3050
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@bmwiedemann