That’s probably the raw milliseconds.
Dates are actually stored as numbers that represent ticks of a certain size from a certain starting point.
milliseconds that have elapsed since midnight on January 1, 1970, UTC.
This date and time are not the same as the UNIX epoch (the number of
seconds that have elapsed since midnight on January 1, 1970, UTC),
which is the predominant base value for computer-recorded date and
And, in the C#
DateTime struct, the ticks are 100 nanoseconds, and are counted since 12:00 midnight on Jan 1, 0001 AD.
So there are some differences. Why would I assume the ones coming from the Project Online REST API are in milliseconds?
Well, for one,
Date constructor. And, in addition to using an ISO string (
"2021-02-10T08:00:00.000Z") or a short date format string (
"2/10/2021"), you can use a number representing milliseconds since Jan 1 1970 in the
Second, I am also assuming that you are sending a header of
That’s all speculation though. I really am just guessing that it’s milliseconds (based on those hunches).
A quick test to see if that’s right? Open up a browser console, and just try it out:
// doing this
Wed Feb 10 2021 03:00:00 GMT-0500 (Eastern Standard Time)
At least, that’s what I get in my time zone. Does that date and time make sense for what you are expecting?
As far as why there is a difference between how REST API date results are formatted for the Project Online API vs. the SharePoint API, I guess that’s a question for the Microsoft development teams…
(As a side note – I haven’t worked with Project Online. I have worked with Project Server 2016 on-prem, and results from the
/ProjectData/ REST API in that version do come back as ISO strings, same as from SharePoint, at least if you are looking at things like