On October 20, 2021, CrashPlan changed times returned in API responses to always be in UTC format. Prior to this change, timestamps could be in UTC time or local time. This change was part of our ongoing work to improve data consistency.
If you use the CrashPlan API to obtain time data, and you utilize the entire ISO 8601 date and time format (including the time offset), this change does not affect you. However, if you use the time obtained from the CrashPlan API as a string value that ignores the ISO 8601 time zone, you may need to make adjustments to your API scripts.
To ensure accuracy of the time output from the CrashPlan API, check that your API scripting does not ignore the time zone.
This change only adversely affects CrashPlan customers who use the CrashPlan API to obtain dates and times, and whose scripting ignores the time zone.
This change does not affect customers who do not use CrashPlan API scripting.
What should I do?
Examine the time output from your CrashPlan API scripting and change any instances that ignore time zone to instead include the time zone information.
Users of the CrashPlan console
Users of the CrashPlan console do not need to take any action. All dates and times displayed in the CrashPlan console correctly show UTC time.
Users of the CrashPlan app
End users of the CrashPlan app on endpoint devices do not need to take any action.
Frequently asked questions
Why are we making this change?
We want to ensure that whenever you see a timestamp on an event that it is always shown in UTC time. Prior to this change, the time could be shown either in UTC time or local time.
How can I be sure that the date and time are correct?
For APIs, the time is returned in ISO 8601 format. In ISO 8601 format, the time in UTC ends with one of the following: "Z" (indicating it is Zulu time), or "+00:00", indicating that the offset from UTC is zero. If you see either of these in the API output, then the time information is correct. If you do not see them, then you are likely consuming the time output as a string value that ignores the ISO 8601 time zone information.
What happens if I don't change my API scripting?
If you allow consumption of time output from the CrashPlan API as a string value that ignores the time zone, people viewing the time will likely interpret it as local time, which is not correct. In addition, if your scripting compares output values by their text representations, it could fail when comparing dates returned before and after the date change.
How can I get help?
If you need help, please contact our technical support team.
We recommend that you subscribe to our announcements page to keep informed about any upcoming changes to CrashPlan functionality that may require you to take action.
Updates to this document
This document should not be interpreted as a legally binding commitment, but rather as an informational document that may change occasionally as we respond to changing market conditions and to our customers' needs.
This document represents the current view of CrashPlan as of the date it was posted. CrashPlan may change or update this policy at any time, without notice. CrashPlan cannot guarantee that this document will be kept up to date, nor that any typographical errors, inaccuracies or omissions will be corrected. Please check this document periodically to keep informed of any changes.
All online policies and similar documents are for informational purposes only. CrashPlan makes no warranties, express, implied or statutory, by posting such documents or about the information in such documents.
Please refer to the Product lifecycle policy document for our general end of support policy.