O365 Rest API Date/Time Fields Adding an Hour Since End of Daylight Savings Time

Question

Here's what is happening in a nutshell. Date/time values for during DST (last week) are stored to reflect the actual local time. However, date/time values since DST ended (this week) are adding an hour to the local date/time.

Below is REST API value returned for 10/31/2015 at midnight (which falls during DST). The value is offset by 7 hours (07:00:00) because the tenant is in Mountain Standard Time.

And below is the value returned for midnight on 11/3/2015 (which falls after DST has ended). Notice that the offset is now 8 hours (08:00:00), which would actually be 1am in MST. Um, why?

This is all fine and dandy because SharePoint appears to be aware of the increment and accounts for it when rendering the value so that users still see midnight on 11/3/2015. However, if you've written JavaScript to populate the date/time value via clientcontext, this is a real problem. I now have to test to see if we are NOT in DST, and add an hour to the time if so. Then, everything works great. Is this really the intended behavior?

Answer 1

This is the response I got from Microsoft Support:

We just wanted to inform you that SharePoint stores date/time as per UTC time and restores it back to regional time from there. As far as the rest API is concerned it is a known issue with it, that is the reason why it is showing a offset of 1 more hour

And this is the fix (hack) I used in my code to get around the problem (I'm using the moment.js library):

        if (!moment(leaveFromVal).isDST())
           leaveFromVal = leaveFromVal + "T01";

        if (!moment(leaveToVal).isDST())
           leaveToVal = leaveToVal + "T01";

It appears that rather than changing their conversion calculation (from UTC to local time), they preferred to change the actual value that was stored so that the same calculation will work both during DST and outside of DST. That does not sound like a best practice to me, but I was not consulted on the matter.

I have not tested to see if this same behavior occurs in on-premise environments.

Cheers! :-)