Due date is shown 1 day earlier

[tolnai]

I have an issue with the due date on the todos, it's showing 1 day in the past for every item. Perhaps UTC/timezone issue?

Here is the HA view, see the test todo shown for October 19:

Here is it on my phone, showing for "today", and currently it's 1:18 am, October 20

Is there something I can do to get the due dates properly, or is this a bug? I tried to check for anything related in the docs, but only found the offset for limiting the retrieved todos, no offset regarding the actual due date values.

[RogerSelwyn]

Please show what is who won in Developer/States, which is what I'm returning. Anything else is down to the HA gui.

[tolnai]

I did complete that daily repeated item, so now it's now on the next day.

Here is it in devtools, showing 10-20

HA showing 10-20 as well

On my phone it is now "tomorrow', so 10-21, so the devstate is showing a wrong date.

I checked debug logs, but nothing related is logged there.

[RogerSelwyn]

I may look in more detail at this later next week.

[tolnai]

Some additional details, that might help.

I checked my microsoft 365 account, it used the default UTC timezone. I changed it to my home timezone 8GMT+1), but after reloading the integration and also waiting some time, it still didn't change anything in HA.

I have a task, which has a due date and a reminder as well.

  due: '2024-10-31'
  reminder: '2024-11-01T14:00:00+00:00'

In my To Do app, the task is due on November 1, and the reminder is at November 1, 15:00 (my local time, in GMT+1).

[RogerSelwyn]

I plan to look at this tomorrow when I have some time. I need to look at how MS deal with due dates and reminder dates because I think there is some weird stuff in there. Then I’ll figure a plan of some sort.

[RogerSelwyn]

Having dug further. This looks like an impossible situation. I am in British Summer Time which is at +1 from UTC at the moment. Examples:

• Todo saved via MS Todo app (on Mac). Due date set to 25/10/24

  "dueDateTime": {
      "dateTime": "2024-10-24T23:00:00.0000000",
      "timeZone": "UTC"
  }

• Todo saved via MS Todo app (on Mac). Due date set to 25/10/24

  "dueDateTime": {
      "dateTime": "2024-10-24T23:00:00.0000000",
      "timeZone": "UTC"
  }

• Todo save via MS Graph explorer. Due Date set as below:

  {
  "dueDateTime": {
      "dateTime": "2024-10-25T12:12:12.1234567",
      "timeZone": "UTC"
  }
  }

  Set date is:

  
  "dueDateTime": {
      "dateTime": "2024-10-25T00:00:00.0000000",
      "timeZone": "UTC"
  }

The integration updates MS365 via the graph api, which is the same as that used by Graph Explorer (where I checked the data above). Clearly the apps (MS Todo and Apple Reminder) are using a different api which allows time to be set on a Due Date. That api seems to let them save a date time (which the [graph api docs](https://learn.microsoft.com/en-us/graph/api/resources/todotask?view=graph-rest-1.0) seem to allow) and setting the value to a time in the local timezone of the client. For something which is essentially a day (no time) this doesn't make sense. The standard for something that is just a date (all the UI's only allow setting a date), is that it should be saved as a Date value not a Datetime.

So from the time that the apps save, given I don't know what timezone the user is in (the Lovelace UI does, but the backend HA server works in a neutral timezone (UTC) since the user could be accessing from anywhere in the world), how do I know from the date time (2024-10-24T23:00:00.0000000) if it is the 25th in a timezone 1 hour out, or 24th in a timezone 23 hours out. (Yes I know no timezones are 23 hours out, but the range is -11 to +14 so there can be an overlap, which will change with Daylight Saving).

If you create/view your todo's via HA, this will work fine, because it will always save as midnight/UTC on the date you set. But of course, this will likely then display wrong in the apps.

Whilst I could just use the date/time received back from the api and present that, I can't save in the same way the apps are. The integration will always save as midnight, it can do nothing else, the api doesn't allow it. The Apps aren't matching that and are interpreting to local timezone and then treating as a date.

So, I really don't have any bright ideas, I'm open to some...

.... Just discovered how the time is offset when saving the Todo, by altering the timezone in the save. Complete madness. I'll see if I can figure something.

[RogerSelwyn]

I've identified that for this to have any chance of working, the underlying python-o365 library needs a change. So this may take a while to fix (if it can be fixed).

[RogerSelwyn]

Clearly MS are storing more date than they are displaying via the api.

I created two todo's, one I set as UTC-10 on 2024-10-24, this is what graph shows:

    "dueDateTime": {
        "dateTime": "2024-10-24T10:00:00.0000000",
        "timeZone": "UTC"
    }

Second todo, I set as UTC+14 on 2024-10-24, this what what graph shows:

    "dueDateTime": {
        "dateTime": "2024-10-23T10:00:00.0000000",
        "timeZone": "UTC"
    }

You will notice that these are 24 hours apart. In the reminder app on iPhone and on MS ToDo app join Mac it shows them both as being due on the 24. So somewhere it is storing the timezone the data was sent it, but it isn't making it available through the api.

[RogerSelwyn]

I've worked a potential solution. Basically, if the time of the task is not 00:00:00, then it will adjust the time by the timezone of the HA server instance. I don't really like this solution, because if someone goes on holiday in a different timezone and creates a task, then the adjustment will not be correct. But without further data, it is impossible to figure out something better.

[tolnai]

Thanks for looking into it. I'll check the above details later, just a quick response about the task time - problem is that in the app I can't specify time, only a date. That means "pick a date".

Edit: time can be picked for reminders, but not for the "due date".

[RogerSelwyn]

Thanks for looking into it. I'll check the above details later, just a quick response about the task time - problem is that in the app I can't specify time, only a date. That means "pick a date".

Edit: time can be picked for reminders, but not for the "due date".

Yes I know, which is why it is a nonsense that the store as a datetime with a timezone.

[tolnai]

Your proposed solution could work, well, definitely better to have issues while on holiday then being off all year long. Or, "round up" time to nearest date? Or allow for a "date offset" config option in the integration.

[RogerSelwyn]

I don’t believe a date offer option will work any better. The problem will be in all cases, where tasks are created in inconsistent time zones. The offset would be needed for each task created (which clearly MS have stored somewhere).

[tolnai]

How about rounding the time? That would work between utc-11 and utc+11. Should be an option however, to leave the choice to the user, since no workaround is perfect. I'd still prefer some workaround than the current behavior.

[RogerSelwyn]

How about +12 - +14? Solution needs to deal with all cases, not just some.

[tolnai]

Well, can you know if noon is -12 or +12 on another day? If you can ok, I didn't check API results that closely.

[RogerSelwyn]

Well, can you know if noon is -12 or +12 on another day? If you can ok, I didn't check API results that closely.

No, unfortunately.

[tolnai]

Then let's make at least people from -11 to +11 happy as a start! 😄 Thanks for spending time with this. Let me know if you need any help/review/etc.

[RogerSelwyn]

I will look to go with the solution I proposed, rather than a solution that is unequal in it's implementation.

[RogerSelwyn]

I have posted a new release with the fix I proposed - https://github.com/RogerSelwyn/MS365-ToDo/releases/tag/v0.1.4

If MS come back at some point and at the timezone to the api, I'll aim to make a better fix.

[tolnai]

I tried it out, updated and due dates now appear to be the same as in the app. Thank you for the fix.