ransome1 / sleek

todo.txt manager for Linux, Windows and MacOS, free and open-source (FOSS)
https://github.com/ransome1/sleek/wiki
MIT License
1.29k stars 99 forks source link

relative due dates off by one: very strange #554

Closed rzw closed 8 months ago

rzw commented 8 months ago

Bug Report

IMPORTANT: Please follow this template strictly when reporting bugs. Providing detailed and accurate information helps the development team to understand and address the issue effectively.

App Version: [1.3.2-rc1]

Platform: [Windows 10]

Installation Method: [Portable: Direct Download]

Bug Description: [I just noticed it today. I have no idea if it is related to this but clocks were adjusted tonight, daylight saving time is over. due:0d is still today but all others are off by one. So due:1d is also today but used to be tomorrow, due:2d is now tomorrow]

Steps to Reproduce:

  1. [just create new item with a relative due date using 0d, 1d, 2d ]

Expected Behavior: [0d used to be and should be today, 1d used to be and should be tomorrow ]

Actual Behavior: [off by one, see bug description]

Additional Information:

Screenshots: [If applicable, include screenshots that demonstrate the bug.]

rzw commented 8 months ago

All is fine today. As I said: very strange. The two test events I created yesterday (due:0d and due:1d) are now seperated and listed in today and tomorrow. Yesterday both were listed in today despite there different relative due dates. My only clue is some malformed daylight saving time logic. The adjustment was yesterday.

ransome1 commented 8 months ago

It could be some issue with how dates are handled by sleek in version 1.x.

Since in 2.x I've switched to a different library to handle the date calculation, I'm curious if this still happens.

The best would be if you would be able to reproduce this behaviour somehow and then to check if the same thing happens with the latest developer preview, which you can find in the GitHub releases.

rzw commented 8 months ago

I can't do this right away. I'll do this on an older laptop. Don't want to mess around adjusting the wrong date on my PC. But I think you're right. Relative dates require calculation and since todo.txt has no time it could be that per default it's 0h (12 AM). So subtracting an hour (wherever and why this happens) on the day of time change puts that event into the previous day

ransome1 commented 8 months ago

@rzw 2.0.0 has been released on GitHub. Please feel free to provide your feedback based on it.

rzw commented 8 months ago

Exciting 🤩

ransome1 commented 8 months ago

@rzw is this still an issue? If not feel free to close the issue, please.