What date and time information should I include in a cloud request?¶
Include the relevant date range, exact times where known, time zone and the reason for the period requested.
The dangerous assumption is that a timestamp without a time zone is precise enough.
What this means in practice¶
Cloud providers may store records in UTC, display them in local time or convert them according to account settings.
Daylight-saving changes, device clocks and exported reports can also create confusion.
If you convert it, retain both the original and converted value.
Where the event time is uncertain, use a justified window that accounts for clock differences, synchronisation delay and provider processing.
For ongoing activity, specify whether the end date is fixed or whether preservation should cover continuing records.
Where several systems are involved, explain that the same underlying action may appear at slightly different times in authentication, audit, application and alert records.
If the relevant conduct crosses midnight or a daylight-saving change, state the full calendar dates and time zone explicitly rather than relying on phrases such as overnight or early morning.
Where the provider accepts only date-based searches, explain the precise event times separately and ensure the requested calendar range includes the whole relevant period in the provider’s likely time standard.
What this may show¶
Include any known event, session, file or correlation identifiers to help the provider locate the right records within the range.
What this does not show on its own¶
Do not make the period unnecessarily broad. A focused range improves proportionality and reduces irrelevant data.
What to do next¶
Record the original timestamp exactly as received and identify its source.
Key takeaway
Give the provider a justified time window, state the time zone and preserve original timestamps so that records from different systems can be compared accurately.