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.

enter image description here

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?

enter image description here

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?

  • Try var dateAndTime = Date.parseLocale("2015-11-03T08:00:00z") and then display Commented Nov 6, 2015 at 4:45
  • 1
    Daylight Savings is a pain, not only in JavaScript calculations, takes me a week to adjust as well... MomentJS and some supporting code makes calculations easier: momentjs.com/timezone Commented Nov 6, 2015 at 8:47

1 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! :-)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.