Unix Timestamp Converter
Paste a Unix timestamp in seconds or milliseconds to see the moment it stands for in UTC and in a time zone of your choice, with daylight saving time applied. Or go the other way and turn a date and time into epoch seconds and milliseconds. The converter also tells you whether the value fits in a signed 32-bit integer, the limit behind the Year 2038 problem.
Updated
Results
- UTC (ISO 8601)
- UTC date and time
- Local time with offset (RFC 3339)
- UTC offsetOffset in force at that moment
- Seconds since the epoch
- Milliseconds since the epoch
- Unit usedTimestamp → date mode
- Fits a signed 32-bit integer?Year 2038 limit: 2,147,483,647 seconds
- Daylight saving noteDate → timestamp mode, only for a skipped or repeated local time
Results are estimates. See the methodology below.
How to use the converter
Timestamp → date
- Paste the number. Seconds can have decimals, such as 1767225600.5.
- Leave the unit on Auto-detect or choose seconds or milliseconds yourself.
- Pick a time zone. You get the UTC time in ISO 8601, a readable UTC line, the local time with its offset and the unit that was used.
Date → timestamp
- Enter the date and the wall-clock time as people in that place read it.
- Pick the time zone of that clock. The result is the timestamp in seconds, plus milliseconds and the UTC equivalent.
The converter doesn't read your computer's clock, so it has no live now value. Paste the timestamp you want to check.
How Unix time works
A Unix timestamp counts the seconds since the epoch, 1970-01-01T00:00:00Z. Negative values are moments before 1970. The POSIX standard defines the count so that every day has exactly 86,400 seconds, so leap seconds are not counted. JavaScript uses the same epoch but counts milliseconds, which gives 13-digit values for current dates.
- Auto-detect: a value of 100,000,000,000 or more (12 digits and up, ignoring the sign) is read as milliseconds. Anything smaller is read as seconds.
- Time zones: the local time comes from the IANA time zone database (names like America/New_York), which records each region's offsets and daylight saving rules over time. Offsets are shown as UTC−05:00 rather than abbreviations like EST.
- Formats: UTC times end in Z, and local times carry a numeric offset in the RFC 3339 style, such as
2025-12-31T19:00:00-05:00. - Range: years 0001 to 9999.
Worked examples
1. From timestamp to date
1767225600 is 2026-01-01T00:00:00Z, midnight on New Year's Day in UTC. In New York it is still Wednesday, December 31, 2025 at 7:00:00 PM (UTC−05:00), and in Phoenix it is 5:00:00 PM (UTC−07:00). Paste 1767225600000 instead and auto-detect reads it as milliseconds, giving the same moment.
2. From date to timestamp
Noon on July 4, 2026 in New York is 1783180800, which is 4:00 PM UTC (New York is on UTC−04:00 in summer). The same instant is 5:00 PM in London and 9:00 AM in Phoenix, which stays on UTC−07:00 all year.
3. Daylight saving edges
| Wall time in America/New_York | Timestamp | What happens |
|---|---|---|
| Mar 8, 2026, 2:30 AM | 1772955000 | Skipped when clocks spring forward. The offset before the change is used, which lands on 3:30 AM (UTC−04:00). |
| Nov 1, 2026, 1:30 AM | 1793511000 | Happens twice when clocks fall back. The first instant (UTC−04:00) is used. |
The second 1:30 AM that night is 1793514600, 3,600 seconds later, at UTC−05:00. Paste it in timestamp mode to check.
4. The 32-bit limit
The largest signed 32-bit value, 2147483647 (2³¹ − 1), is 2038-01-19T03:14:07Z. One second later, 2147483648, is marked as overflow. The smallest, -2147483648, is 1901-12-13T20:45:52Z.
Frequently asked questions
Is my timestamp in seconds or milliseconds?
Count the digits. Current dates are 10 digits in seconds and 13 in milliseconds. Auto-detect uses the 12-digit cut-off, so a millisecond value from before March 3, 1973 is too small and gets read as seconds. For example, 86400000 means January 2, 1970 in milliseconds but September 27, 1972 as seconds, so pick the unit yourself for old or unusual values.
What is the Year 2038 problem?
Software that stores Unix time in a signed 32-bit integer can't count past 2,147,483,647 seconds, which is 3:14:07 AM UTC on January 19, 2038. The next second wraps around to a negative number, which reads as December 1901. Systems that use 64-bit time don't have this limit. The int32 line shows whether your value fits.
Why do I get an out-of-range error?
The converter handles years 0001 to 9999. A 16-digit microsecond value (from some databases and logs) falls far outside that range: divide it by 1,000 to get milliseconds first. A 12-digit value that really is seconds, after the year 5138, would be read as milliseconds by auto-detect, so choose seconds explicitly.
Does a Unix timestamp depend on the time zone?
No. The number identifies one instant worldwide. Only its local display changes: 1767225600 is 7:00 PM in New York and midnight in UTC. When you convert a date to a timestamp, the time zone matters because it tells the converter which clock the time came from.
When does daylight saving time change in the US?
Under federal law, DST starts at 2:00 AM on the second Sunday of March and ends at 2:00 AM on the first Sunday of November. States may opt out, and America/Phoenix in the list stays on standard time. In 2026 the changes fall on March 8 and November 1, as the table above shows.
Sources
Conversions use the IANA time zone data in your browser and ignore leap seconds, as Unix time does. Check critical timestamps against the system that produced them.