In the Agenda component, automatically retrieve preferred timezone for the current user

[waldekmastykarz]

Proposal: In the Agenda component, automatically retrieve preferred timezone for the current user

Rationale

Retrieving events from the calendar using the current user's preferred timezone is necessary to properly take into account start and endtime of events. Automating the retrieval of the preferred timezone will simplify working with the Agenda component and lower the amount of custom code that developers need to write and maintain.

Preferred Solution

<mgt-agenda use-preferred-timezone="true"></mgt-agenda>

use-preferred-timezone is a boolean that determines whether the preferred timezone should be included in the request or not. Since including the preferred timezone is important, we should consider setting its default value to true and have developers disable it explicitly. It would lead to a breaking change comparing to the current behavior, but since current v2.0 is still in preview, perhaps that's acceptable.

Additional Context

Related to #681

[ghost]

Hello waldekmastykarz, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[michaelmaillot]

I can have a look at this feature 🙂

If I understand correctly, the goal is to get current user's timezone if the parameter use-preferred-timezone is set to true and if so, add in the background the timezone offset to date filters, right?

How this can be achieved? With the /me/mailboxSettings endpoint like @waldekmastykarz suggested? If so, it would require to have MailboxSettings.Read permissions at least.

[waldekmastykarz]

I wonder if we'd need to call Graph or if we could rely on the standard JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone property. Let's check with the Graph team if values from the timeZone property are accepted in Graph and take it from there.

[gavinbarron]

@waldekmastykarz the agenda component has moves to using IANA time zones for a number of reasons, mostly due to Windows time zones being awful and non-standard.

We have couple of problems when it comes to showing a Date in a windows time zone:

• When requesting events in anything but UTC it's impossible to know what the UTC offset should be in the client as the DateTime doesn't have the UTC offset section
• A given Windows time zone translates to a number of IANA time zones, some of which may use different Daylight savings change times, especially when considering historical data.
• Browsers have no notion of Windows time zones.
• Browsers do have support for shifting a UTC Date to a given IANA time zone for adjusting the date and time for display due to a lack of data start and end properties for events (i.e. no UTC offset provided) and there is native browser support for moving a UTC time to a given IANA time zone I'm not sure that this is a useful feature.
• A user may have their compute clock set to a time zone other than their preferred time zone.

To further complicate this there are libraries that can convert windows - iana time zones but they are all massive, and not really weight I want to add to the library if we can avoid it.

Also by default events in the Agenda are normalized to match the current UTC offset that the device is supplying.

Given all that, do we need this feature?

[waldekmastykarz]

We need to ensure that whatever data we show, they match they users' expectations. I'd say that their calendar is leading and we should align with it. If we already do, then we wouldn't need this change.

[sebastienlevert]

Are we mixing things here? We are talking about displaying, but I feel this is not about this. It's about retrieving the data based on the right time zone. When the data is returned, then we should just display it as is. Correct?

[gavinbarron]

The problem is, well, dates. We get our dates as ISO8601 formatted strings and need to render them as "human" readable dates, this requires us to construct a Date object from the string provided.

When you fetch calendar events from Graph and specify the "time zone" the data you get back is relative to that "time zone" This is all well and good if the requested "time zone" and the system clock of the client machine match.

If they don't match there is no happy path to ensuring correct display without pulling in some rather heavy additional dependencies. Browsers work with IANA time zones, Microsoft Graph work with Windows time zones. When you specify the time zone the dates returned are not in UTC, nor do they provide metadata that provides a UTC offset.

In order to make this work it would be necessary to: Load the user's preferred Windows time zone via a call to Graph Map that Windows time zone to a corresponding IANA time zone Hope that the selected IANA time zone doesn't have a variation of daylight savings time adjustments from the IANA time zone which the user is actually in.

I'll note that the hoping is a real thing here for the upcoming year as the US intends to move forward to DST and never fallback again. Currently the "Pacific" time zone includes America/Vancouver and America/Los_Angeles. If Canda doesn't follow the lead of the US then there's a real possibility of showing incorrect data here for many users.

Honestly the Graph API here feels like it's built on the assumption that you can talk entirely in Windows time zones and not the international standard.