A Unix timestamp represents an instant as an amount of time since the Unix epoch: January 1, 1970 at 00:00:00 UTC. Timestamps are convenient for storage and comparison because they do not include a formatted month name or local time-zone label.
Use the QuickToolsBox Timestamp Converter to compare a timestamp with a readable date in your browser.
Seconds and milliseconds
Traditional Unix time counts seconds. Many JavaScript systems count milliseconds instead. Confusing the two is the most common timestamp error.
A current timestamp in seconds usually has 10 digits. The equivalent millisecond value usually has 13 digits. For example:
Seconds: 1761393600
Milliseconds: 1761393600000To convert seconds to milliseconds, multiply by 1,000. To convert milliseconds to whole seconds, divide by 1,000 and decide how the fractional part should be handled.
UTC and local time
The timestamp identifies an instant; UTC is the reference used to interpret it. A user interface may display that instant in New York, London, Tokyo, or another local zone. The clock reading changes, but the instant does not.
When debugging, write down all three pieces of information:
- The original numeric value
- Whether it is seconds or milliseconds
- The time zone used for display
Without those details, a date can appear wrong even when the stored timestamp is correct.
How to convert a timestamp
- Copy the numeric value without surrounding labels.
- Determine whether the source uses seconds or milliseconds.
- Paste it into the timestamp converter.
- Compare the UTC result with the expected local time.
- Check whether the source system rounded away fractional seconds.
ISO 8601 and Unix time
An ISO 8601 string is designed for readable data exchange. A value such as 2026-10-25T16:00:00Z includes a date, time, and the Z indicator for UTC. Unix time stores the same kind of instant as a number.
ISO strings are easier to inspect in logs. Numeric timestamps are convenient for arithmetic and compact storage. Either can work when the format, precision, and time zone are documented.
Common timestamp problems
A date near 1970
The application probably treated milliseconds as seconds incorrectly, divided more than once, or received a very small value.
A date thousands of years in the future
The application probably treated a millisecond timestamp as seconds.
An offset of several hours
The value may be correct while one layer displays UTC and another displays local time. Check the zone rather than manually adding or subtracting an offset.
Daylight-saving errors
Named regions such as America/New_York contain historical and daylight-saving rules. A fixed offset such as -05:00 does not describe every date in that region. Use a proper time-zone database for calendar scheduling.
Parsing a date without a zone
A string such as 2026-10-25 09:00 does not identify a unique instant until a time zone is assigned. APIs should document whether zone-less input is local time, UTC, or invalid.
Frequently asked questions
Can Unix timestamps be negative?
Yes. Negative values represent instants before the epoch, although some older systems and data types may not support them correctly.
Do Unix timestamps include leap seconds?
Common Unix time handling does not represent leap seconds as distinct numbered seconds. Systems may apply their own clock-smearing or synchronization behavior.
What will happen in 2038?
Signed 32-bit seconds overflow in January 2038. Modern 64-bit systems have a much larger range, but old software and embedded systems still need review.