-
Notifications
You must be signed in to change notification settings - Fork 91
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.
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
:lastweek
doesn't count last Sunday
#493
Comments
Configuration (just in case):
|
OK, seems like it comes from the system configuration:
So I will need to reconfigure my system (MSYS2), it seems. |
I guess that check was flawed. The right one should search for
This returns nothing on MSYS2. But it returns an integer value on my Ubuntu:
|
Well, my hypothesis regarding LC_TIME settings seems to be wrong, at least on Ubuntu 20.04: I have configured my locale, where I set both
This week now starts on Monday, 2022-07-04:
Let's reinitialize the TimeWarrior DB:
TimeWarrior searches for tracks in seemingly the correct time range:
Now if I reconfigure locale by setting both
... this week starts on Sunday, 2022-07-03:
I reinitialize TimeWarrior DB again:
... but TimeWarrior still searches for tracks up to the 2022-07-04T00:00 (start of Monday) for some reason:
Which now is off by one day. It seems that So on Ubuntu it starts counting a week on Mondays. Does anyone know how TimeWarrior calculates start and stop of the week? |
:lastweek
doesn't count Sunday:lastweek
doesn't count last Sunday
The start of week is "calculated" by |
@lauft do you mean this? int Datetime::weekstart = 1; // Monday, per ISO-8601. taskwarrior has |
I stumpled upon the same problem and I think I've found another root cause. If I change a single line in helper.cpp and subtract 6 from end day instead of 7, it works. My guess is that the :lastweek range ends at Saturday 23:59:59 (Sunday is NOT included in the range) instead of Sunday at midnight (Monday at 0:00:00). Below is what I did:
|
Thanks, @perdalum! I noticed this exact issue and your patch did the trick. |
It seems to me that the issue is that the
Then shifting calculations happen and afterwards the range end is assigned a
But the |
There is no The issue is that while start of week is You can run timew with debug to see a hint of the dates being evaluated: timew :debug :lastmonth summary |
The
That's a different and unrelated to
In the case of IMHO, using "start of next X" in most hints is incorrect in general, but I don't rule out that there's a reason, that I'm not aware of, for doing it this way. |
I've checked the rest of the hints and they all include midnight of the next day after their actual span. So I guess that's intended behavior, even though not what I initially and intuitively expected. There's an issue with |
So, is there a fix for this being implemented? It looks like the most obvious fix is the one proposed by @egyptianbman and @perdalum , maybe one of you could submit PR for this? Thanks for looking into this |
ping @lauft :) |
I favor the fix changing the code from using This is in line with the changes made in lines 148-154 when the |
With GothenburgBitFactory/taskwarrior#2519, all 'end of *' named dates have been changed to be the last minute of the respective date. This caused the ':lastweek' hint to miss the last day of its range. Closes #493 Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
Cleaning the state:
Mark up last week (it start from monday here):
Let's check the time spent:
For some reason
:lastweek
misses the second track (from Sunday), even if:month
shows the same week number for both tracks.The text was updated successfully, but these errors were encountered: