User's time zone is lost in all day meetings

[raimille1]

Bug Report

Prerequisites

• [ X] Can you reproduce the problem?
• [ X] Are you running the latest version?
• [ X] Are you reporting to the correct repository?
• [ X] Did you perform a cursory search?

For more information, see the CONTRIBUTING guide.

Description

All day events are created and shown in the user's calendar without a problem through outlook.com for example. I'm on America/Sao_Paulo, and when configuring an all day event I see it starts properly at 03:00 UTC and ends at 03:00 UTC the next day. But when I retrieve that same event through the API, I don't see any indicators that this all day event was created in that time zone. I understand that "All day" means a specific date, period but in many cases this is an issue to the client of the API.

Console Errors: Not applicable

Screenshots:

Steps to Reproduce

• A User configures a day off (2023-01-23 through 2023-01-24 midnight to midnight their time zone) that shows them as busy in their calendar, to make it more apparent, let's say they're -6 hours from UTC.
• We, a scheduling platform (kalendme.com) are looking for available times to meet late afternoon 2023-01-22, let's say at 8 pm. So we check against their events we retrieved using MS Graph API, and we see they're busy.
• The issue here comes since all events from the MS graph api come in ISO, and that's ok but they also include the time shift, Except all day events. So we store that busy event from 2023-01-22T00:00:00 UTC until 2023-01-23T00:00:00 UTC (2023-01-22T18:00:00Z-06:00 until 2023-01-23T18:00:00Z-06:00) instead of 2023-01-23T06:00:00 until 2023-01-24T06:00:00.
• If the event had a single reference to the proper time shift of the user, specific all day events would be able to be transformed back without having the need to retrieve the user's mailbox time zone from anywhere else just like we do with regular events.

If a client of the API does not really care about the time zone and just the date of the all day event, that's ok too, they can check the isAllDay flag and move on, but clients that that do need it cannot work without all the information.

Expected behavior: [What you expected to happen]

The all day event should come back from 2023-01-23T06:00:00Z (UTC) until 2023-01-24T06:00:00Z (UTC). While indicating it's al all day event (this already exists) so API consumers can decide whether to use the time portion of the timestamp or not.

Actual behavior: [What actually happened]

All day events come back for this user as if they're from 2023-01-22T00:00:00 UTC until 2023-01-23T00:00:00 UTC

Additional Context

Usage Information

SDK Version - 3.0.1

• [X ] Node

Node Version - v16.18.1

[sebastienlevert]

Thanks for your question @raimille1! It appears the API only stores the date and overrides the time and timezone information to make it midnight on UTC. It seems to be the actual behavior of the underlying API and I would argue it should be like this.

This appears to be an issue or limitation with the service APIs. Unfortunately, as the Microsoft Graph SDK team, we do not have ownership of the APIs that are causing you issues. We invite you to create a question about the service API to Microsoft Q&A and tagged with one of the microsoft-graph-* tags, that way it will get routed to the appropriate team for them to triage.

I will be closing the issue for now, but feel free to re-open it. Please let us know if this helps!

[raimille1]

Thanks for clarifying @sebastienlevert !! Yeah I imagined it would be something along those lines. I do agree it should return it in UTC, all I was saying is that somewhere the API client should be able to know what's the user time zone in case the Date itself is referring to the local date or UTC date like the case I showed. The user's all day event is actually in their local time zone, event if it's an all day event for them.

[sebastienlevert]

You could use the mailboxSettings API to get the user's timezone instead of getting it via the event. https://learn.microsoft.com/en-us/graph/api/resources/mailboxsettings?view=graph-rest-1.0

[raimille1]

Yeah I read about it but asking all our users for yet one more oauth scope just for that seems like overkill. The other provider's we're integrated with, including Google return the original time zone somewhere in the event itself. For Microsoft, we're now accessing the user's configured time zone in our platform as a fallback.