Sorting game history by clock text can reverse the real order
Published — UTC
A later-looking clock value can represent an earlier instant. When two game-history sources use different offsets, sorting their printed local times is not a reliable chronological comparison.
Convert both records to one offset
The following timestamps are invented and use the same calendar date. RFC 3339 supplies the offset notation; these calculations use new examples.
| Record | Source timestamp | Equivalent UTC |
|---|---|---|
| A | 2026-10-12T18:10:00+08:00 | 10:10:00Z |
| B | 2026-10-12T17:45:00+07:00 | 10:45:00Z |
A's printed hour is larger, but A occurs 35 minutes before B. Subtract eight hours from A and seven from B before comparing. Sorting only 17:45 and 18:10 would reverse the event order.
Keep the source field
Use a normalized timestamp for sorting and retain the original timestamp beside it. Do not overwrite the source date or infer an offset from the website's audience. A server, account and browser can use different settings.
If an offset is absent, the instant is unresolved. Adding +08:00 simply because the reader is in the Philippines can manufacture a chronology the export did not provide. Request the field definition or label the comparison uncertain.
Order is not proof of causation
Even a correct order cannot prove that one transaction caused another. A retrieval timestamp may describe when a page was collected rather than when a round settled. Keep event time, settlement time and retrieval time separate.
Carry the date when crossing midnight
A third invented record, 2026-10-13T00:15:00+08:00, is 2026-10-12T16:15:00Z. Subtracting the offset changes the date as well as the hour. Saving only “16:15” beside the original October 13 date would place it a full day late.
A complete normalized field therefore retains year, month, day, time and offset convention. The display can be localized for a reader afterward, while the sortable instant stays unchanged.
Different strings can identify the same instant
2026-10-12T18:10:00+08:00 and 2026-10-12T17:10:00+07:00 both equal 10:10:00Z. Sorting the normalized instants correctly produces a tie. A stable secondary key can make the output reproducible, but an arbitrary ID order is not evidence that one tied event happened first.
Likewise, timestamps rounded to a minute may hide differences of seconds. Preserve supplied precision; do not invent fractional seconds to force an order. A known clock delay or a source that records batch processing may also limit what the sequence proves.
Choose the timestamp for the question
A round accepted at 10:10, settled at 10:12 and downloaded at 10:45 has three legitimate timestamps. Use acceptance time to order accepted rounds, settlement time to reconstruct posted awards where appropriate, and retrieval time to document collection. Sorting all three fields together would interleave different kinds of event.
If a stake and return must be linked, use their documented round or transaction relationship rather than simply pairing neighboring timestamps. Correct conversion solves the offset problem; it does not establish missing identities, clock accuracy or cause and effect. Keep a record with an unspecified time zone unresolved until its source convention is known.