What date and time information should I include in a cloud request?¶

State a justified date range, exact event times where known, the time zone for every value and whether the period must cover continuing activity. A timestamp without a zone - or a phrase such as “overnight” - does not define a reliable cloud search.

Preserve the source time before converting it¶

Providers may store events in UTC, display them in an account's local zone or apply a zone during export. Retain each original timestamp exactly with its source and stated zone, then add any normalised value separately.

If the period crosses midnight or a daylight-saving change, give full dates and explicit offsets. Where a provider accepts only whole-date searches, choose dates that include the relevant instant in the provider's likely time standard and explain the wider boundary.

Allow for how systems record an action¶

Authentication, application, audit and alert systems may timestamp different stages of the same activity. Network delay, processing queues, synchronisation and imperfect device clocks can also produce small differences. When the event time is uncertain, request a reasoned buffer rather than pretending to know an exact instant.

Known event, session, correlation and resource IDs help locate the right records within that window. For ongoing incidents, distinguish a fixed historical request from preservation that should continue beyond the issue date.

Keep the period no broader than the evidence question reasonably requires. Account identifiers tell the provider where to search; accurate time information tells it when.