Pillar Guide
타임스탬프 및 타임존 가이드
A practical reference for converting timestamps, comparing zones, and avoiding the off-by-hours mistakes that break scheduling and reporting.
Most time bugs are not caused by arithmetic. They come from unspoken assumptions: a backend stores UTC but the frontend displays local time, a report labels a date without including its zone, or a timestamp in seconds is mistaken for milliseconds. Once that happens, the symptom looks random even though the root cause is consistent.
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.
관련 읽을거리
가이드와 워크플로
관련 도구
도구 라이브러리