SP REST API returns incorrect date (timezone offset incorrect)

[diabhoil]

Category

• Bug

Describe the bug

When I try to get the modified date of a file the response contains a date format like this "2020-02-19T09:28:39-08:00". The correct time would be 09:28 in GMT+1 (Berlin Timezone), so the time value is correct, but not the timezone offset. When I try to make a js date with the returned value, I get a totally wrong date "Wed Feb 19 2020 18:28:39 GMT+0100", which would be 9 hours in the future for me. I could just trim the timezone offset at the end or change it to a correct value, but that would be a nasty workaround and maybe just working for my tenant.

Steps to reproduce

Write a spfx webpart and try to get file data with the client:

let fileUrl: string = webUrl + "/_api/Web/GetFileByServerRelativePath(decodedurl=%27" + this.state.documentUrl + "%27)";
let itemUrl: string = fileUrl + "/ListItemAllFields";
context.spHttpClient.get(url, SPHttpClient.configurations.v1).then((response: SPHttpClientResponse) => { return response.json().then((data: any) => {}); })

Expected behavior

At least a date in UTC time like the search api is returning.

Developer environment

SPFX 1.8.2
SharePoint Online
Edge Beta, Chrome

Not sure if its related to spfx at all or if the sharepoint rest api is wrong here. Any help would be nice.

best regards
diabhoil

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[Dennis-LZ]

Please add ISPHttpClientOptions to the SPHttpClient.get method.

Modify the code as below.

const httpClientOptions: ISPHttpClientOptions = {
	headers: {
		'Accept': 'application/json;odata=nometadata',
		'Content-type': 'application/json;odata=nometadata',
		'odata-version': ''
	}
};
let fileUrl: string = webUrl + "/_api/Web/GetFileByServerRelativePath(decodedurl=%27" + this.state.documentUrl + "%27)";
let itemUrl: string = fileUrl + "/ListItemAllFields";
context.spHttpClient.get(itemUrl, SPHttpClient.configurations.v1, httpClientOptions).then((response: SPHttpClientResponse) => { return response.json().then((data: any) => {}); })

Check the similar thread here: #1684

Dennis Guo
Microsoft SharePoint Community Support

[diabhoil]

Thank your for the response but I tried that already with no success. Even double checked if the header was send. I have read the related issues already and searched a lot before posting. I am getting the same results when just using the URL in the browser bar. Guessing it is not a framework issue...more a SharePoint rest problem. The SharePoint is adding a wrong timezone offset after the correct timestamp which is imo just wrong.

[andrewconnell]

@Dennis-LZ that's not a good solution... you're suggesting to override from an OData v4 request => v3 (when none is specified, SP REST defaults to v3). The recommendation is to use v4, which is set by the SPHttpClient.configurations.v1.

@diabhoil Can you check the NETWORK tab on the browser, find the request, and inspect the raw response? Please share the results of the response. Also share a screenshot of the request object (with ALL the request headers).

I doubt it's an issue with SPFx's SPHttpClient object... I'm mostly certain it just returns the data it receives... that's what my request above is trying to confirm.

If that's correct, then it would be a question to the REST team...

[msft-github-bot]

The more context details you can provide, the easier it is to help assist on issues. Any code you can provide and/or screenshots of the issue also help. The easier you can make it to reproduce the issue, the easier and quicker it is for someone to help you. Please refer to How to Create Good Issues, specifically How to Create Good Issues: Include context, in our wiki for more details.

[diabhoil]

thx for the response @andrewconnell

Here is the response (removed all unnessary parts) and sorry for not making screenshots.

{
    "@odata.context": "https://tenant.sharepoint.com/sites/xxxxxxx/_api/$metadata#SP.ListData.Freigegebene_x0020_DokumenteItems/$entity",
    "@odata.type": "#SP.Data.Freigegebene_x0020_DokumenteItem",
    "@odata.id": "XXXXXX",
    "@odata.etag": "\"4\"",
    "@odata.editLink": "Web/Lists(guid'XXXXX')/Items(5)",
    "FileSystemObjectType": 0,
    "Id": 5,
    "ServerRedirectedEmbedUri": null,
    "ServerRedirectedEmbedUrl": "",
    "ContentTypeId": "0x010100XXXXX",
    "OData__ModerationComments": null,
    "ComplianceAssetId": null,
    "Title": "Test 19.02., 9.30",
    "OData__ModerationStatus": 0,
    "ID": 5,
    "Created": "2020-02-19T09:28:39-08:00",
    "AuthorId": 18,
    "Modified": "2020-02-19T09:33:19-08:00",
    "EditorId": 18,
    "OData__CopySource": null,
    "CheckoutUserId": null,
    "OData__UIVersionString": "1.0",
    "GUID": "XXXX"
}

Here are the response headers:

HTTP/2 200 OK
cache-control: private, max-age=0
content-type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
content-encoding: gzip
expires: Thu, 06 Feb 2020 21:01:54 GMT
last-modified: Fri, 21 Feb 2020 21:01:54 GMT
etag: "XXXXXXXXX,4"
vary: Accept-Encoding
p3p: CP="ALL INDCNT COM INT E PUR UNI"
set-cookie: xxxx; domain=sharepoint.com; expires=Wed, 26-Feb-2020 20:55:45 GMT; path=/; SameSite=None; secure; HttpOnly
set-cookie: FedAuth=xxxxxxxx; expires=Wed, 26-Feb-2020 20:55:45 GMT; path=/; SameSite=None; secure; HttpOnly
x-sharepointhealthscore: 3
x-sp-serverstate: ReadOnly=0
odata-version: 4.0
spclientservicerequestduration: 129
x-aspnet-version: 4.0.30319
sprequestguid: XXXX
request-id: XXX
ms-cv: XXX
strict-transport-security: max-age=31536000
x-frame-options: SAMEORIGIN
x-powered-by: ASP.NET
microsoftsharepointteamservices: 16.0.0.19729
x-content-type-options: nosniff
x-ms-invokeapp: 1; RequireReadOnly
x-msedge-ref: Ref A: XXX Ref B: XX Ref C: 2020-02-21T21:01:54Z
date: Fri, 21 Feb 2020 21:01:54 GMT
X-Firefox-Spdy: h2

And here are the request headers

Host: tenant.sharepoint.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
Accept: application/json;odata.metadata=minimal
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://tenant.sharepoint.com/sites/XXXX/SitePages/Documents.aspx?d=https://tenant.sharepoint.com/sites/XX/Freigegebene%20Dokumente/XXXX.png&i={YYY}&t=png
OData-Version: 4.0
SdkVersion: SPFx/XWebPart/Y
DNT: 1
Connection: keep-alive
Cookie: MicrosoftApplicationsTelemetryDeviceId=X; MicrosoftApplicationsTelemetryFirstLaunchTime=2020-02-21T20:56:12.061Z; WSS_FullScreenMode=false; cucg=0; stsSyncAppName=Client; stsSyncIconPath=; FeatureOverrides_enableFeatures=; FeatureOverrides_disableFeatures=; rtFa=sdgsdg; hibext_instdsigdipv2=1; SPWorkLoadAttribution=Url=https://tenant.sharepoint.com/sites/XX/SitePages/Documents.aspx&AppTitle=RenderClientSideBasePage
Pragma: no-cache
Cache-Control: no-cache
TE: Trailers

editted by @andrewconnell to make it readable, please see this on how to include code blocks in your comments so there's no line wrapping

fyi: Request was send with firefox on win10 german lang, spfx in debug mode. Tested this behaviour on several tenants, in german/english environments (browser/os/sitecollection lang)

The creation date was 2020-02-19 09:28 AM german time (GMT+1, UTC+1)

[andrewconnell]

In the future, please follow the standard GH guidance on pasting code to an issue... that was impossible to read until I edited it. More details here.

This isn't a SPFx issue, this is related to the SharePoint REST API. You can see from your raw response, you're getting "Modified": "2020-02-19T09:33:19-08:00", back from your response. According to what you're saying, the timezone offset is incorrect... agreed?

[diabhoil]

Sorry for the bad code structure and thx for correcting 👍

Yes I have seen the raw response. Tested in Browser, but was not sure if it is maybe a request problem (wrong config or something like that).
Yes the timezone offset is incorect. The time when I modified the document was 9:33 AM (UTC + 1, Berlin/German timezone). With the response of 2020-02-19T09:33:19-08:00 javascript (and me by just reading it) thinks this timestamp is 9 hours (again german time) in the future.

[andrewconnell]

OK... renaming the issue to be more descriptive... need to verify on other tenants first...

[andrewconnell]

I'm not sure why you are getting data back in the way it's being returned. I expect to see the format like 2020-02-22T11:48:16Z.

Just tested in 3 of my tenants and everything looks correct, both the date notation in ZULU notation returned & in the accuracy of the value. Not sure if something specific is going on with your tenant... you may need to open a support ticket via your SPO tenant admin...

[andrewconnell]

@diabhoil Try this... just to be explicit on the response...

Copy the request you see in the Network tab as a fetch request:

Paste it into the Console and make sure the request headers ask for data as JSON & use the v4 format:

Execute... then look at the response in the Network tab... here's what I'm seeing... which is correct & expected:

[diabhoil]

@andrewconnell Ok. But my problem is exactly with the /listitemallfields call. All other calls returning the correct date.

This is a different tenant and browser now. Just to be 100% sure that its not just our companys tenant.

Here is the response. Modified it at 13:11 (german local time)

Which would result in

The resulting timestamp would be in the future for me.

[diabhoil]

Posting the settings for the sitecollection (same in both tenants). Maybe it is helping here

[JBPuzzled]

Hi all,

Is there an update on this? I'm experiencing the same issue here in the Netherlands, currently summer time (UTC+2).

Let me describe actions and results.

In the context of a SharePoint Online site I use the following JavaScript to get the created date from versions of a file:

import { sp } from "@pnp/sp/presets/all";
const item = await sp.web.lists.getByTitle("Documenten").items.getById(862).versions.select("VersionLabel", "Created").get();
console.log("item: ", item);

This results in:

However in the context of a SPFx Extensions project I experience issues with the created date.

The following dependencies are used among others:

    "@microsoft/sp-core-library": "1.9.1",
    "@microsoft/sp-dialog": "1.9.1",
    "@microsoft/sp-listview-extensibility": "1.9.1",
    "@microsoft/sp-build-web": "1.9.1",
    "@microsoft/sp-module-interfaces": "1.9.1",
    "@microsoft/sp-tslint-rules": "1.9.1",
    "@microsoft/sp-webpart-workbench": "1.9.1",

For the example I followed the steps from Andrew Connell. First I copy the request as a fetch request:

Second, I executed it in the console and created a screenshot of the results:

[diabhoil]

I have no update sorry. We changed to an other api call (/_api/Web/GetFileByServerRelativePath) to get the correct dates in our project. We had this problem only with the "listitemallfields" call.

[ghost]

This issue is being closed as part of an issue list cleanup project. Issues with no activity in the past 6 months that aren't tracked by engineering as bugs were closed as part of this inititive. If this is still an issue, please follow the steps outlined to re-open or submit a new issue.

[ghost]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues