Timestamp & Timezone Guide

The first question: what is the source timezone?

Do not start by converting numbers. Start by naming the original timezone, the display timezone, and the format boundary between them. If any one of those is implicit, the conversion is already risky. A reliable workflow documents all three before release notes, cron jobs, or meeting schedules are generated.

The mistakes that cost teams hours

The biggest one is mixing seconds and milliseconds. The second is serializing a local wall-clock time as if it were UTC. The third is displaying an ISO string without telling the user which zone it represents. Every one of those bugs can survive unit tests if the test data never crosses a DST boundary or a cross-region handoff.

• Label every human-readable time with an explicit zone in docs and UI.
• Keep raw epoch values beside formatted strings during debugging.
• Test one example across at least two regions before shipping scheduling logic.

A practical browser check

Convert the timestamp into UTC first, then into the destination timezone, then compare it against the original business expectation. If the task involves date arithmetic, run that step separately instead of combining arithmetic and timezone conversion in one mental jump. That separation catches more mistakes than any amount of guesswork.