microsoft-graph-toolkit
microsoft-graph-toolkit copied to clipboard
microsoftgraph
[mgt-agenda] Render the date strings from the response as they are
Closes #1507
PR Type
- Bugfix
Description of the changes
Create the ISO 8601 date strings manually. This helps to:
- leave out the timezone offset part. When you do
new Date().toISOString()you create the object in UTC. Doing it manually, you can calculate the offset on the object and recreate the string with the local timezone. This avoids the one day offset bug. - Set the
preferred-timezonefor your return values without messing the start and end dates.
PR checklist
- [x] Project builds (
yarn build) and changes have been tested in at least two supported browsers (Edge + non-Chromium based browser) - [x] All public APIs (classes, methods, etc) have been documented following the jsdoc syntax
- [x] Stories have been added and existing stories have been tested
- [x] Added appropriate documentation. Docs PR:
- [x] License header has been added to all new source files (
yarn setLicense) - [x] Contains NO breaking changes
Other information
Thank you for creating a Pull Request @musale.
This is a checklist for the PR reviewer(s) to complete before approving and merging this PR:
- [ ] I have verified a documentation PR has been linked and is approved (or not applicable)
- [ ] I have ran this PR locally and have tested the fix/feature
- [ ] I have verified that stories have been added to storybook (or not applicable)
- [ ] I have tested existing stories in storybook to verify no regression has occured
- [ ] I have tested the solution in at least two browsers (Edge + 1 non-Chromium based browser)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Can you refine a little bit the scenarios for us to test? Right now when using my local time zone I'm still 1 day off (in the future).
<mgt-agenda group-by-day date="May 7, 2019"></mgt-agenda>
This PR is becoming dependent on this bug : https://github.com/microsoftgraph/msgraph-sdk-javascript/issues/529
This PR is becoming dependent on this bug : microsoftgraph/msgraph-sdk-javascript#529
My solution does not need this encoding URI.
I get the expected results for this:
<mgt-agenda group-by-day></mgt-agenda>
<mgt-agenda group-by-day date="May 8, 2019"></mgt-agenda>
<mgt-agenda group-by-day date="May 8, 2019" preferred-timezone="Africa/Nairobi"></mgt-agenda>
<mgt-agenda group-by-day preferred-timezone="Africa/Nairobi"></mgt-agenda>
When using <mgt-agenda group-by-day preferred-timezone="Japan/Tokyo"></mgt-agenda> I would expect getting a UTC+9 and we are getting UTC.
When using
<mgt-agenda group-by-day preferred-timezone="Japan/Tokyo"></mgt-agenda>I would expect getting a UTC+9 and we are getting UTC.
I have made an update which can't be tested using the sandbox. This is because when you add the Prefer: 'outlook.timezone="xx"' it doesn't return the values with the requested time zone. It confused me for a while and it has contributed to most of the issues I have faced in this fix. It behaves the same way in GE. However, when I signed in with my account, I got it to work.
To explain it further;
- When I don't use the
Prefer: 'outlook.timezone="xx"'header, I get the following response:
"start": {
"dateTime": "2022-02-03T18:00:00.0000000",
"timeZone": "UTC"
},
"end": {
"dateTime": "2022-02-03T18:45:00.0000000",
"timeZone": "UTC"
}
That means the server defaulted to UTC and everything returned has the dates in UTC.
- When I set the
Prefer: 'outlook.timezone="Australia/West"header, the response was:
"start": {
"dateTime": "2022-02-04T02:00:00.0000000",
"timeZone": "Australia/West"
},
"end": {
"dateTime": "2022-02-04T02:45:00.0000000",
"timeZone": "Australia/West"
}
That's the same time as the UTC one above but in Australia/West timezone. I realized that most of the code that rendered the date/time was changing this values to UTC and that gave the offset values that we were experiencing. This is the value you want to show the user so the problem is fixed by displaying that value. I deduct the time zone offset from the time and get a new Date object I can use for the various rendering scenarios.
- This is the response from
Prefer: 'outlook.timezone="Asia/Tokyo":
"start": {
"dateTime": "2022-02-04T03:00:00.0000000",
"timeZone": "Asia/Tokyo"
},
"end": {
"dateTime": "2022-02-04T03:45:00.0000000",
"timeZone": "Asia/Tokyo"
}
To test this, you have to use an actual application because the tenant apps for testing are not returning values with the timezone updates.
@musale There are styling issues with prettier when merging the latest of the main branch over there.
What is the status of this? Can we try to merge this if ready for showtime? @musale @gavinbarron
What is the status of this? Can we try to merge this if ready for showtime? @musale @gavinbarron
I haven't had a look at this in a while @sebastienlevert. However, the last time I needed an extra pair of eyes from a different time zone to test this out - the tenants have a time zone changing issue mentioned above. @gavinbarron maybe you can have a look before it's merged? Also, I would like @waldekmastykarz input on it if he doesn't mind 😄
I've been trying to wrap my head around this one, the challenge I'm having is that I can't get GE or mgt.dev to provide responses that align with the Prefer: outlook.timezone="<time-zone>"' header to help me understand what's going on.
I'll be digging into it more today.
