"Someday" should be sorted at the end (after tasks with no duedate) when sorting by end date

[Gert-dev]

Hi

Thanks for maintaining this application. I've been using it with satisfaction for quite some time, and wanted to ask a question - possibly suggest an improvement - around the ordering of tasks when sorting by the end date column.

Currently, when sorting tasks in an ascending fashion by end date, you see:

1. Task A that ended five days ago.
2. Task B that needs to be done tomorrow
3. Task C that needs to be done at date Z in the future, but within the current year.
4. Task D with "someday" as end date.
5. Task E that needs to be done at date Y in the future, but not this year.
6. Task F with no end date set.

For example:

Two things strike me as somewhat odd here: one is that apparently "someday" is seen as "somewhere within the current year", whilst I thought the purpose of it was "it needs to be done at some point, but it has no required end date, so don't show it in the Open view either", implying low priority - in the screenshot, the task due by 2023 is sorted after "someday" tasks, though.

The other thing is that I'm wondering if it would make more sense to always sort "someday" tasks at the far bottom, and sort the tasks with no end date before them. The reasoning is that tasks without end date might still need to be done in the near future ("soonish"), whilst for "someday" tasks priority doesn't matter - in a sense, tasks with "someday" have an end date that is later than tasks without an end date. Currently, if you have a lot of tasks "someday", they are all sorted before tasks that might be more "urgent", pushing them down.

There may be a reasoning for the current sorting, though, and maybe it just comes down to preference.

Thanks!

[Neui]

About the current sorting, it seems for "someday" for comparing dates it is turned into a date where it is a year from now (aka today):

gtg/GTG/core/dates.py

Lines 201 to 203 in 4dd1648

	now = datetime.now()
	delta_days = {SOON: 15, SOMEDAY: 365, NODATE: 9999}
	gtg_date = Date(now + timedelta(delta_days[self.dt_value]))

[nekohayo]

I wholeheartedly agree that this sorting doesn't make sense. This is just a wild guess, but this might historically have something to do with how sorting the GtkTreeview works, and if so, it might be something for @diegogangl and @jaesivsm to consider as part of #737 / New Core / GTK4 / new views ... so many moving pieces interacting with each other there!

Surprised we didn't already have a ticket for this issue here, I probably never noticed because I spend my time in "Actionable" view so much, which hides the "someday" tasks.

[diegogangl]

We can compare fuzzy dates directly in the new filter models in Gtk4, so we can get away from the limitations of using days for fuzzies.