Elapsed time from the UTC epoch
Unix time counts from 1970-01-01 00:00:00 UTC. A value of zero is that exact instant.
The timestamp does not store a region; the same instant is formatted differently in UTC and local time.
Ten-digit and thirteen-digit values
Current second values are commonly around ten digits and millisecond values around thirteen. Misreading the unit produces an implausibly distant date.
Check automatic detection and prefer the documented unit of the source system.
- Seconds: seconds since epoch
- Milliseconds: seconds × 1,000
- 1 second = 1,000 milliseconds
Compare local time with UTC
Korea Standard Time is nine hours ahead of UTC. UTC 00:00 displays as 09:00 on the same date in Korea.
When comparing browser, database, and server logs, identify which systems store UTC and which store local values.
Daylight saving and ambiguous strings
Regions using daylight saving can change offset by date; one fixed offset may create a one-hour error.
A date string without zone information may be interpreted locally. Prefer ISO values with an explicit zone in APIs.
Distinguish seconds from milliseconds first
A Unix timestamp measures time from 1970-01-01 00:00:00 UTC, commonly in seconds or milliseconds. Contemporary second values are usually ten digits and millisecond values thirteen, a factor of 1,000. The wrong unit can produce a date near 1970 or far in the future, so check both digit count and API documentation.
Fractional seconds may represent subsecond precision, while some systems store microseconds or nanoseconds. Do not rely on length alone; inspect the database type and generating code. Label shared log values with unit=seconds or milliseconds to prevent later reinterpretation.
- Current seconds are commonly 10 digits
- Current milliseconds are commonly 13 digits
- Confirm the documented storage unit
Read UTC and local time as the same instant
A timestamp identifies an instant; a time zone changes its display. 2026-09-02 00:00 UTC is 09:00 in Korea. Those are not separate events. Before diagnosing a nine-hour error, determine whether the source was UTC or local time.
A zone-free string such as 2026-09-02 09:00 may be interpreted differently by environments. In ISO 8601, append Z for UTC or an offset such as +09:00. Storing UTC and formatting for the user's region usually makes cross-system comparison clearer.
- UTC and local clocks can show one instant
- Use Z for UTC
- Include an explicit offset for local time
Handle daylight saving and date boundaries
Korea currently has no daylight-saving clock change, but many regions do. Converting New York 09:00 with a permanent UTC-5 offset is wrong during daylight time. For future schedules, use an IANA zone such as America/New_York with current zone data rather than a fixed offset.
An event near local midnight may fall on the previous or next UTC date, changing daily totals. Define the reporting time zone for signups, sales, and expirations, then use it consistently in SQL, analytics, and dashboards. Test duplicated or nonexistent local times around DST transitions.
- Distinguish fixed offsets from named zones
- Declare the time zone used for daily totals
- Test bookings and recurrence on DST transitions
Practical validation checklist
After conversion, cross-check the date against the source screen, a known event time, or another standards-based converter. A result around 1970 or millennia ahead suggests a unit error. A constant eight- or nine-hour difference suggests zone interpretation, one hour may suggest DST, and a day may come from a midnight boundary.
Before changing data, record the original number, assumed unit, display zone, and conversion rule, then test on a copy. Leap-second handling, integer limits, and the year-2038 issue can vary by implementation. For payments, authentication, and legal deadlines, follow the service's documented time policy and authoritative logs.
- Cross-check against a known event
- Use the error size to diagnose unit or zone
- Record the rule before modifying source data