Developer Tools
View live Unix seconds and milliseconds, convert reliable 10-digit or 13-digit timestamps into UTC, local and ISO 8601 values, or convert a local browser date back to both epoch units without silently guessing ambiguous inputs.
Current Unix time
Timestamp → date
Date → timestamp
Interpreted in your browser timezone: UTC.
Simple workflow
How to use Unix Timestamp Converter
- 1Enter a Unix timestamp or local date.
- 2Choose the conversion direction.
- 3Review the local, UTC and epoch values.
Good to know
Frequently asked questions
How does automatic seconds or milliseconds detection work?
Auto-detect accepts 10 digits as seconds, 13 digits as milliseconds, and zero as seconds. For any other length, choose the unit explicitly so an ambiguous value is not guessed.
Does timestamp conversion use a server or save dates?
No. The browser converts the value and formats UTC and local results in this tab. Entered timestamps and local date-time values are not uploaded or retained by UtilSprout.
Practical guide
Translate epoch values without silently guessing their unit
A Unix timestamp represents elapsed time from the Unix epoch at 1970-01-01 00:00:00 UTC. APIs commonly use whole seconds, while JavaScript and some logs use milliseconds. Auto-detect accepts 10-digit values as seconds, 13-digit values as milliseconds, and zero as seconds; other lengths require an explicit unit.
A timestamp identifies an instant independently of a display time zone. The result shows that instant as ISO 8601 and UTC, then formats the same value in the browser's current local zone.
Worked example
Compare seconds with milliseconds
- Start with
- Enter 1704067200, then compare it with 1704067200000.
- Choose
- Leave Unit on Auto-detect and convert each value.
- You get
- The 10-digit value is interpreted as seconds and the 13-digit value as milliseconds. Both represent 2024-01-01T00:00:00.000Z and therefore show the same local instant.
Tips for a useful result
- Choose Seconds or Milliseconds explicitly for historical, negative, shortened or unusually long values; digit count alone is not enough to identify those safely.
- Use the UTC or ISO result when systems in different time zones need one unambiguous instant.
- Entered values are parsed in this browser. They are not uploaded, stored by UtilSprout or included in analytics.
Seconds or milliseconds decision table
Auto-detection is intentionally narrow. It avoids converting an ambiguous value to a plausible but incorrect date.
| Timestamp input | Interpretation |
|---|---|
| 0 | Auto-detect treats the Unix epoch value as seconds. |
| Exactly 10 digits | Auto-detect treats the value as whole seconds since the epoch. |
| Exactly 13 digits | Auto-detect treats the value as whole milliseconds since the epoch. |
| Any other length | Auto-detect reports the value as ambiguous. Select Seconds or Milliseconds explicitly; the converter never chooses a unit from magnitude alone. |
Local time, daylight saving time and the 2038 boundary
The Date to timestamp input contains a local wall-clock date and time but no time-zone offset. The browser interprets it in the device's current time zone. During a daylight-saving transition, a local time can be skipped or can occur twice; the browser runtime decides how that wall time maps to an instant. Confirm the resulting UTC value when the exact offset matters.
The Year 2038 problem concerns systems that store signed Unix seconds in 32 bits: 2,147,483,647 seconds reaches 2038-01-19 03:14:07 UTC. This browser tool uses JavaScript dates and can display later supported values, but a receiving legacy database, device or protocol may still have a 32-bit limit.
Authoritative external sources
- The Open Group: Seconds Since the Epoch (external)
The POSIX definition relating seconds since the epoch to UTC calendar fields.
- RFC 8536: The Time Zone Information Format (external)
An IETF specification documenting 32-bit transition-time limits that include the 2038 boundary.
Understand the details
Related reference guide
Keep going