Unix Timestamp Converter
Convert Unix seconds or milliseconds to dates and local date-times back to timestamps.
- Free
- No signup
- Runs in your browser
The date-time input is interpreted in this browser’s local timezone. ISO output is UTC.
How it works
How to use
Choose seconds or milliseconds, then convert a timestamp or local date-time.
Method
The browser converts between Unix time, local time, and UTC ISO output.
Example
Unix timestamp 0 corresponds to the start of 1970 UTC.
If the converted date looks absurd, check the unit first
Unix timestamps are commonly exchanged in seconds or milliseconds, and the number itself does not carry a label telling the converter which unit its producer used. SnakTool therefore makes you choose the unit instead of guessing it from the value.
A seconds value interpreted as milliseconds often lands close to 1970. A millisecond value interpreted as seconds can point implausibly far into the future or exceed the date range the browser can represent. Before changing timezones or correcting the number, confirm the unit expected by the API, database or log that produced it.
1704067200 seconds
1704067200000 milliseconds
Both → 2024-01-01T00:00:00.000ZOne timestamp can have many clock displays
A Unix timestamp identifies an instant rather than a timezone. SnakTool shows that instant as an ISO UTC value and also as the browser's local date string, so the hour—and sometimes the calendar date—can differ while the underlying moment stays the same.
Changing from UTC display to local display does not add or subtract time from the timestamp. It changes the clock and timezone used to describe the same instant. This is why two developers in different timezones can see different local times for one shared timestamp without either conversion being a different moment.
Unix timestamp
│
├── UTC ISO representation
└── Browser local representationThe timestamp is global; the date you type is local
The reverse direction has an important asymmetry. A local date-time field such as 2026-06-15 12:00 does not contain a UTC offset, so SnakTool passes that value through the browser's Date interpretation and the device timezone determines which instant that wall-clock time represents.
After conversion, the resulting Unix timestamp identifies that instant independently of timezone. The same visible local date and time entered on devices configured for different timezones can therefore produce different timestamps. When a system requires a specific timezone or offset, preserve that information outside this local date-time input rather than assuming the converter knows it.
Daylight-saving changes make some local clock times unusual
Timezone rules can move local clocks forward or backward. During a forward transition, some wall-clock times may not occur; during a backward transition, a local time can occur more than once. A bare local date and time does not contain enough information to resolve every such case on its own.
SnakTool does not provide a timezone selector or a daylight-saving disambiguation control. The browser's local Date rules interpret the entered value. Unix timestamps themselves do not have this ambiguity because each numeric timestamp identifies one instant.
Milliseconds disappear when you ask for whole seconds
When a local date is converted to milliseconds, SnakTool returns the browser's millisecond timestamp directly. When seconds are requested, it divides that value by 1000 and truncates the result with Math.trunc.
That means fractional seconds are discarded rather than rounded to the nearest second. A time ending in .999 seconds remains in the current whole second when converted to seconds. Choose milliseconds when the receiving format needs sub-second precision.
1710000000999 ms
÷ 1000 = 1710000000.999
Math.trunc → 1710000000 sZero is a date, not an empty timestamp
Timestamp 0 is the Unix epoch itself: 1970-01-01T00:00:00.000Z. Values immediately around zero make the number line easier to read: positive timestamps point after the epoch and negative timestamps point before it.
This also explains a familiar debugging symptom. If an application unexpectedly displays a date around January 1970, the source may have supplied zero, a small value, or a seconds value that another layer mistakenly interpreted as milliseconds.
-1 second → 1969-12-31T23:59:59.000Z
0 seconds → 1970-01-01T00:00:00.000Z
1 second → 1970-01-01T00:00:01.000ZDates before 1970 live on the negative side of the line
The epoch is an origin, not the earliest date that can be represented. SnakTool accepts finite negative timestamp values and converts them when JavaScript Date can represent the resulting instant.
External systems may impose narrower rules of their own, so a negative timestamp that converts in the browser is not proof that every database, protocol or API will accept it. Check the range required by the system receiving the value.
2038 is a storage boundary in some systems, not the end of Unix time
The well-known Year 2038 problem comes from storing Unix seconds in a signed 32-bit integer. Its maximum positive value is 2147483647, corresponding to 2038-01-19T03:14:07.000Z; adding another second overflows that legacy representation.
SnakTool does not store timestamps in a signed 32-bit integer, so that boundary is not a built-in limit of this converter. A value can still fail when it falls outside JavaScript Date's supported range, and an external system can have its own smaller numeric range.
2147483647 s
→ 2038-01-19T03:14:07.000ZTen and thirteen digits are clues, not a unit specification
Current positive Unix timestamps are often about 10 digits in seconds and 13 digits in milliseconds, which makes digit count a useful debugging clue for modern dates. It is not a universal rule: historical values, negative values and unusually distant dates can have different lengths.
SnakTool supports seconds and milliseconds only. Microsecond and nanosecond timestamps need their unit and precision handled elsewhere rather than being pasted here and interpreted by digit count.
A timestamp locates an instant; it does not measure a duration
The number 86400 can be read as a Unix timestamp 86,400 seconds after the epoch, which identifies 1970-01-02T00:00:00.000Z. Separately, 86,400 seconds is also a duration of 24 hours. Those uses share a number but describe different concepts.
Use timestamp conversion when the value represents a point on the Unix time axis. If the value means elapsed time between events, treat it as a duration and apply the units and calendar rules appropriate to that calculation.
Frequently asked questions about Unix Timestamp Converter
Does the seconds mode retain milliseconds?
No. SnakTool divides the millisecond value by 1000 and applies Math.trunc, so fractional seconds are discarded rather than rounded. Use milliseconds when the receiving format requires sub-second precision.
Does a Unix timestamp contain a timezone?
No. It identifies an instant relative to the Unix epoch. UTC and local dates are different clock representations of that same instant.
What is a Unix timestamp?
A Unix timestamp represents an instant as elapsed seconds or, in some systems, milliseconds relative to the Unix epoch. SnakTool lets you explicitly choose seconds or milliseconds.
Are Unix timestamps in seconds or milliseconds?
Both conventions are widely used. Traditional Unix time is expressed in seconds, while JavaScript and many APIs use milliseconds. SnakTool requires you to select which unit your value uses.
Why are UTC and local time different for the same timestamp?
They use different timezone representations of the same instant. SnakTool shows an ISO UTC value and the browser's local Date string, so the displayed hour or calendar date can differ without changing the timestamp.
Can local times be ambiguous during daylight-saving changes?
Yes. A backward clock transition can repeat a local time, while a forward transition can skip local times. This converter does not provide a timezone or DST-disambiguation control and relies on the browser's local Date interpretation.
Can I convert dates before 1970?
Yes when JavaScript Date can represent the date. The resulting Unix timestamp is negative, although another system receiving that value may impose a narrower range.
What is Unix timestamp 2147483647?
In seconds it represents 2038-01-19T03:14:07.000Z, the maximum positive Unix-seconds value of a signed 32-bit integer.
Does converting milliseconds to seconds round the value?
No. SnakTool uses Math.trunc after dividing by 1000, so the fractional-second portion is discarded rather than rounded.
Why can the same local date and time produce a different timestamp in another timezone?
A local date-time input contains no UTC offset. Browsers in different local timezones can therefore map the same wall-clock text to different instants and different Unix timestamps.