due today ends at 15:00 #2989
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2989
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
TZ: Asia/Shanghai, not sure if relevent
Expected: Should it be 00:00 tomorrow?
Vikunja Frontend Version
0.20.2
Vikunja API Version
0.20.1
Browser and version
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Can you reproduce the bug on the Vikunja demo site?
Yes
Screenshots
If you don't provide a date when creating a new task it will use the nearest date, similar to the date picker. In your case you seem to have created the task after 12:00 and before 15:00, hence Vikunja picked 15:00 as the time.
I am also confused by this. Shouldn't this pick midnight as due date for today?
TBH I don't get it.
The way it is currently implemented, no. Vikunja looks for the next time in three-hour intervals (excluding night).
I guess this is what is confusing me.
If I write 'today' what I would mean personally is that that task should be done 'any time today' meaning the due date should be either at midnight or even a bit later since 'my day' – in the sense of my being-awake time – usually ends after midnight.
If I write 'in the next few hours' the current setting would be fine. Maybe even for 'now'. I wouldn't expect the due date to include an hour if I didn't define one.
I think this returns to the discussion we had in #809.
The issue is the api expects to save the due date with a time. Hence we need to pick one when the user does not provide one.
You are right! For a quick fix I think that change would improve UX a lot. We should really rebase and merge #1378 .
The latter only fixes the view part though.