fix the year 2038 problem in getDateTime
The existing codes cast uint64_t into time_t which is int32_t in
most 32-bit systems. It results overflow if the timestamp is larger
than INT_MAX.
time_t will be 64 bits in future releases of glibc. See
https://sourceware.org/bugzilla/show_bug.cgi?id=28182.
This change workarounds the year 2038 problem via boost's ptime.
std::chrono doesn't help since it is still 32 bits.
Tested on QEMU.
Example output for certificate:
{
"Name": "HTTPS Certificate",
"Subject": null,
"ValidNotAfter": "2106-01-28T20:40:31Z",
"ValidNotBefore": "2106-02-06T18:28:16Z"
}
Previously, the format is like "1969-12-31T12:00:00+00:00". Note
that the ending "+00:00" is the time zone, not ms.
Tested the schema on QEMU. No new Redfish Service Validator errors.
Signed-off-by: Nan Zhou <nanzhoumails@gmail.com>
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I8ef0bee3d724184d96253c23f3919447828d3f82
diff --git a/redfish-core/lib/task.hpp b/redfish-core/lib/task.hpp
index 22e9743..b7795a7 100644
--- a/redfish-core/lib/task.hpp
+++ b/redfish-core/lib/task.hpp
@@ -388,11 +388,11 @@
asyncResp->res.jsonValue["Name"] = "Task " + strParam;
asyncResp->res.jsonValue["TaskState"] = ptr->state;
asyncResp->res.jsonValue["StartTime"] =
- crow::utility::getDateTime(ptr->startTime);
+ crow::utility::getDateTimeStdtime(ptr->startTime);
if (ptr->endTime)
{
asyncResp->res.jsonValue["EndTime"] =
- crow::utility::getDateTime(*(ptr->endTime));
+ crow::utility::getDateTimeStdtime(*(ptr->endTime));
}
asyncResp->res.jsonValue["TaskStatus"] = ptr->status;
asyncResp->res.jsonValue["Messages"] = ptr->messages;