Date, time, and schedules
What date is this 10- or 13-digit timestamp?
Tools to use
Date bugs often begin with an unstated unit: seconds read as milliseconds, or UTC compared with local clock time. Correct numbers can then produce surprising dates. Separate the unit from the display convention before adding offsets to make the result look right.
Unix Time reads an integer timestamp under an explicitly selected unit and shows UTC plus a chosen timezone. It does not decide the unit from digit count. Start with zero, then use a known date to reproduce a seconds/milliseconds mismatch.
Zero stays zero in Tokyo; the clock display changes
UTC: 1970-01-01T00:00:00Z
Asia/Tokyo: 1970-01-01T09:00:00+09:00These represent one instant. You do not add nine hours to the Unix value to display it in Tokyo. A timezone change reads the same instant on another clock; adding nine hours afterward changes the instant as well and applies the adjustment twice.
A log containing only 2024-01-01 09:00 lacks a timezone. The clock reading alone cannot distinguish 09:00 UTC from 09:00 Tokyo. Include an offset such as Z or +09:00, or a zone name, when sharing a timestamp.
1704067200 means different dates under different units
1704067200 seconds → 2024-01-01T00:00:00Z
1704067200 milliseconds → 1970-01-20T17:21:07.2ZSeconds gives New Year's Day 2024; milliseconds gives January 1970. The same instant in milliseconds is 1704067200000, a factor of 1,000 larger. Do not adjust digits by trial and error: check the producer's unit first.
Ten digits for seconds and thirteen for milliseconds is only a heuristic for familiar dates. Values near 1970, negative timestamps, and distant dates have other lengths. Even a field named timestamp needs a documented unit in the API or storage contract.
Verify the reverse conversion with an explicit offset
2024-01-01T00:00:00Z
2024-01-01T09:00:00+09:00Convert each separately from date to epoch. In seconds, both yield 1704067200. Equal epoch values reveal a display difference rather than a shifted instant. Avoid offset-free date strings in reproducible tests because their interpretation can depend on the environment.
For fractional-second timestamps, distinguish whole-second fields from the value expressed in the selected unit. Reducing millisecond logs to integer seconds loses ordering within a second. Define the precision you need and check for discarded digits during conversion.
A date-only value is not automatically an instant
A date such as 2024-01-01 contains neither a clock time nor a timezone. Converting it to an instant requires an additional convention. Turning birthdays or business dates into midnight UTC for convenience can show the previous day elsewhere. Keep date-only information as dates when that matches its meaning.
Use calendar-date difference for days between dates, and elapsed-time mode for seconds between instants. A calendar day is not invariably 24 elapsed hours. State the question before choosing an input form, especially around timezone transitions.
Correct conversion does not prove a correct source clock
A few seconds between server logs can remain after units and zones agree. This tool converts timestamp meaning; it does not measure clock synchronization or network delay. Also check whether each log records start, finish, client time, or receipt time.
A convertible value is not proof that it belongs to the right event. Check for a copied wrong column or a changed producer contract. Choose one known event and compare its value, unit, UTC display, and local display to isolate the layer responsible.
Share the value and unit together
Report '1704067200 Unix seconds, 2024-01-01T00:00:00Z in UTC', optionally adding Asia/Tokyo as the display zone. Missing units or zone context force recipients to guess. Preserve labels when copying results instead of forwarding only a number.
Keep fixed tests for zero, a known date, equivalent second/millisecond values, and reverse conversion with offsets. Tests based only on now change every run. Fixed examples catch unit confusion and double offset adjustments after implementation changes.
Aligning timestamps does not prove event order
Logs at 2024-01-01T09:00:00+09:00 and 2024-01-01T00:00:00Z describe the same instant: Unix seconds 1704067200. Converting both avoids mistaking a zone difference for latency. But second-resolution logs cannot order events within that second. Multiplying to milliseconds adds zeroes, not missing measurement detail.
Clock skew between devices can also reverse the apparent order despite correct conversion. Correlate request IDs and processing relationships rather than inferring causality from this tool alone. Record original values, units, display zone and logging resolution. Converting representation, checking clock synchronization and establishing event order are separate steps.