Convert seconds since the Unix epoch into a local date and time, or enter a local date to obtain a timestamp. The clock and conversions use your browser’s time zone.
Runs locally in your browserA Unix timestamp counts elapsed seconds from 1970-01-01 00:00:00 UTC. This page interprets date and time input in the browser's local time zone.
Store timestamps in UTC. Apply a named IANA time zone, including daylight-saving rules, only when displaying a value to a user.
| Environment | Current timestamp | Convert timestamp to UTC date and time |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(timestamp * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(timestamp, timezone.utc) |
| PHP | time() | (new DateTimeImmutable("@$timestamp"))->setTimezone(new DateTimeZone("UTC")) |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(timestamp) |
| Go | time.Now().Unix() | time.Unix(timestamp, 0).UTC() |
| Ruby | Time.now.to_i | Time.at(timestamp).utc |
| PostgreSQL | SELECT EXTRACT(EPOCH FROM NOW())::bigint; | SELECT TO_TIMESTAMP(timestamp) AT TIME ZONE 'UTC'; |
| MySQL | SELECT UNIX_TIMESTAMP(); | SELECT FROM_UNIXTIME(timestamp); |
This page converts seconds since the Unix epoch into a date and time in your browser's time zone, and converts a local date and time back into a timestamp. A live clock shows the current value and can be stopped to freeze a reading.
Every conversion uses the time zone reported by your browser, so the result matches the clock on your own machine rather than UTC. Subtract the offset shown next to the result when you need the UTC value, or work with the ISO form when the wire format matters.
Unix time counts the seconds that have elapsed since 1970-01-01T00:00:00 UTC, ignoring leap seconds, so it is a simple integer rather than a calendar structure. It is always defined in UTC, which is why the same value printed in two time zones shows two different wall clocks but still refers to one instant.
Because leap seconds are ignored, Unix time is not a precise count of elapsed physical seconds, but it is consistent enough that every operating system, database and language uses it as the default interchange format for instants. This is also why a timestamp is often called epoch time or POSIX time.
The classic value is in seconds and is ten digits long for dates between 2001 and 2286. JavaScript and Java use milliseconds, which gives thirteen digits, and some systems store microseconds or nanoseconds, giving sixteen or nineteen. A value that looks like it belongs to the year 50000 is almost always milliseconds being read as seconds, and a value far in the future is the same mistake in the other direction.
When you send a timestamp to an API, check the unit in its documentation and watch for the mismatch where a client sends milliseconds and the server stores seconds. The visible symptom is a date decades in the future, which is a quick way to identify the bug.
A timestamp has no time zone, but a date does. Two servers writing midnight in their own local time write two different timestamps, which is why logs and databases should store the instant and convert only for display. Daylight saving shifts make the reverse conversion ambiguous: one local wall-clock time can occur twice, and one can be skipped entirely.
Systems that store Unix time in a signed 32-bit integer overflow in January 2038, when the counter passes 2,147,483,647. Modern 64-bit platforms are unaffected, but embedded systems, older databases and file formats that still use 32-bit fields are worth checking before that date.
Accepts a Unix timestamp (seconds since 1970-01-01 UTC) or a date and time string, and outputs the counterpart value based on browser local time.
Inspect timestamps in server logs, match UTC epoch values in database records to local wall time, and generate epoch seconds for scheduled jobs.
The Unix timestamp and date/time input are processed in browser JavaScript; the working input is not uploaded to VoriTools.
Date and time input is interpreted in the browser's local time zone; conversions near a daylight-saving transition may be ambiguous because no IANA zone selector is provided.
The conversion uses your browser's local time zone, while your server, log or database is probably writing UTC. Both sides are showing the same instant; only the offset differs. Compare the timestamp values rather than the displayed clocks to confirm.
It is in milliseconds, which is what JavaScript's Date.now() returns. Divide by 1000 and round down to get the seconds-based value that most APIs and databases expect.
In JavaScript use Math.floor(Date.now() / 1000); in PHP time(); in Python int(time.time()); in Java Instant.now().getEpochSecond(); and in a shell, date +%s. All of them return the same integer for the same instant.
On systems that store Unix time in a signed 32-bit integer, the counter overflows on 19 January 2038. 64-bit systems are fine for hundreds of billions of years, so the issue is limited to older or embedded platforms and to file formats with a 32-bit time field.
No. It treats every day as exactly 86,400 seconds, so it drifts from astronomical time by about a second per year. For scheduling, logging and measuring durations that is irrelevant, and it keeps arithmetic predictable.
Use ISO 8601 when a human has to read or compare the value, when the time zone has to be explicit, or when sub-second precision is needed. Use Unix time for storage, arithmetic and comparisons, because it is a plain integer with no parsing rules attached.