`list view` not sorting by date

List view is not putting oldest tasks first.

Addressing in this PR: #802

Turns out that while I was sorting datetimes correctly, I was counting dates without times as having no datetimes for the purpose of sorting.

I should have thought of that previously, my work with the API and filtering had required I make some interesting math logic around date/times (date with time, date without time, no datetime..).

Some of the solutions count without time as automatically at 23:59 on the same day, or at 0:00

In my task completion dashboard/data vis I have a case statement for time calculation like this:

Who knew such a simple thing is so complicated...

DateTimes break my brain! And Rust doesn't make it easier 😆 . Yeah I'm coming to the same conclusion that I need to convert dates to datetimes at 23:59:59!

The additional complication is that tasks can be created with 'fixed' and with 'floating' timezones (see https://todoist.com/help/articles/set-a-fixed-time-or-floating-time-for-a-task-YUYVp27q)

So, the end result will be the following:
-Tasks with no due date will have a null/empty due date
-Tasks due on a specific date, but not time, will have a due.date, but nothing under due.datetime
-Tasks due on a FLOATING specific date AND time will have a due.date and a due.datetime in plain date HH:MM:SS format (i.e. 6/9/2024 13:00:00), and no due.timezone data. This is because these will be in the LOCAL timezone, and be shown due at different times in the Todoist client depending on the client.
-Tasks due on a FIXED specific date and time will have a due.date, a due.datetime, and a due.timezone. The due.datetime will be in an IS8601 datetime format (ending in Z), in UTC, and need to be mapped to the appropriate timezone.

Is there any handling done for times currently? Are times rewritten from UTC to local time, or is everything handled to local time? (and I'm sure nothing is being done with floating vs fixed, but I'm OK with treating everything as fixed for the time being)

I think that this is handled well at the moment, if you take a look at

tod/src/time.rs

Line 56 in 7673dbc

    
           pub fn datetime_from_str(str: &str, timezone: Tz) -> Result<DateTime<Tz>, Error> {

you can see that I am taking the datetime string and using UTC for Zulu time, and otherwise getting datetime from config. So the goal is to get everything to a DateTime with timezone, and then I can format them from there.

Does that make sense?

Also, this fix is now released as part of 0.6.10, check it out!