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

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.