Epoch Converter & Live Unix Timestamp Clock

Hey, no need to memorize timestamp arithmetic to know when an event occurred. Paste the value, select the timezone that matters and let the converter do its job.

The important thing is to know what you got. A Unix timestamp is usually the number of seconds since the epoch, but in JavaScript it's often milliseconds. But one missing or extra three zeros and a perfectly ordinary 2026 event is sent back to 1970. They describe the same kind of moment, but one missing or extra three zeros and a perfectly ordinary 2026 event is sent back to 1970.

#Start with the value you have

You can use below converters when the direction is clear:

• Epoch to Date turns a Unix timestamp into a readable date.
• Date to Epoch turns a date, time, and timezone into Unix seconds or milliseconds.
• Unix Timestamp Reference provides useful current, daily, weekly, monthly, and yearly timestamp boundaries.
• Timezone Converter helps when the instant is known but its display needs to change.

The live clock above is handy if you want to quickly copy the current time in seconds for a Unix style API, or milliseconds for JavaScript and browser code.

#What a Unix timestamp really means

Unix time is the number of seconds since the epoch, which is defined as 1970-01-01 00:00:00 UTC. That number is a point in time on the UTC timeline but it does not store timezone, locale or display format .

That separation is why timestamps work nicely between systems. A server in Singapore, a database in Frankfurt and a laptop in Chicago can all hold the same integer, and agree on the event that it represents . Each can then display it in its own local time, without changing the actual moment.

Unix time does not take into account leap seconds. Usually you want that for application work. It's consistent with the POSIX convention used by operating systems, databases, logs, and APIs.

#Seconds and milliseconds: the three-zero pitfall

Most command-line tools, database functions, and API fields that say “Unix timestamp” mean they are seconds while JavaScript's Date.now() returns milliseconds. Both values may look plausible, that is exactly why this bug is so common.

Value	Unit	Same instant
1700000000	Unix seconds	2023-11-14T22:13:20Z
1700000000000	Epoch milliseconds	2023-11-14T22:13:20.000Z

For modern dates the number of digits is a useful first clue:

• 10 digits generally means Unix seconds.
• 13 digits often means javascript style epoch milliseconds.

The converters of this website use that practical distinction to make ordinary conversions faster. It is a convenience, but not a universal law. An archival record, a deliberately far-future test date, or a value copied from a system that uses microseconds needs an explicit unit. When an API documents a field as seconds or milliseconds, trust the documentation over the digit count.

In code, the conversion is intentionally boring:

const seconds = 1700000000;
const milliseconds = seconds * 1000;

new Date(milliseconds).toISOString();
// "2023-11-14T22:13:20.000Z"

The other way is to divide by one thousand. Only use Math.floor() if the system you are sending to expects a whole integer of Unix seconds.

#Convert an epoch value to a date

If a log, webhook, database row, or API response gives you a timestamp, you can start with Epoch to Date. The converter will show the result as:

• an ISO 8601 format UTC string, for logs and for APIs;
• a UTC date and time, useful when comparing systems;
• a human-readable date in the time zone you chose;
• a relative description for quick human context.

For example, 1700000000 becomes 2023-11-14T22:13:20Z. Change the display timezone and the clock time changes, but the timestamp does not. Think of the timestamp as the pin on a map, a timezone is the label next to it.

#Convert a date and time to Unix time

Converting a date and time to Unix timestamp has one more decision to make: which timezone did it mean?

“June 20 at 9:25 AM” is not a unique instant until it is paired with a timezone. It might be 09:25Z, 9:25 AM in New York, or 9:25 AM in Tokyo -- three different points of time. Go to the Date to Epoch tab. Enter the calendar date, time and IANA timezone, hit the convert button and then copy the resulting timestamp.

This is important for scheduled jobs, event signups, billing cutoffs, and reminders. This is also important at the time of daylight-saving transitions, where a local clock time may occur twice or not at all. Save the timestamp result for the event itself, and also save the named timezone in which the schedule is defined by local wall-clock time.

#UTC, local time, and named timezones

The safest common display for technical work is UTC, because it provides every reader with the same clock. ISO 8601 strings with a letter Z in ending are UTC:

For example,

2026-06-20T09:25:00Z

But for user-facing output, better to choose an IANA timezone such as America/New_York, Europe/London, or Asia/Tokyo. IANA names are preferable over a fixed offset like -05:00 because they follow local daylight-saving rules when applicable.

One useful habit that will prevent a surprising number of incidents: Specify the timezone on server rendered pages, scheduled emails, screenshots, and tests. Otherwise, the runtime might use its own local time zone. It's the same moment but your server just decided to read it on a different clock.

#Precision Beyond Seconds

Usually, seconds and milliseconds are used, but some systems use smaller units:

Unit	Common use	Note
Second	Unix APIs, JWT claims, shell tools	The classic Unix timestamp
Millisecond	JavaScript, browser events, many web APIs	Date.now() returns this unit
Microsecond	Some databases and tracing systems	Better to confirm the field contract
Nanosecond	High-resolution runtimes and measurements	Often requires BigInt or a string

Do not treat a 16 or 19 digits number as self-explanatory. It could be microseconds or nanoseconds since the Unix epoch, but it could also be a different epoch altogether. Chrome / WebKit timestamps, .NET ticks, and several database formats have their own reference dates. The unit and the epoch are bound up together.

For measuring a duration, rather than recording when an event happened, use a monotonic clock such as performance.now() in browser or Node.js code. Wall clocks can be adjusted; elapsed time should not jump backward because a machine corrected itself.

If you want to measure how long something takes, use a monotonic clock like performance instead of logging the time of an event.now() in the browser or in Node.js code. A wall clock is adjustable while an elapsed time cannot go backward in time because a machine corrected its own fault.

#The Year 2038 boundary

The most famous timestamp edge case is the Year 2038 problem . A signed 32 bit integer can only hold a maximum of 2147483647 seconds which is:

2038-01-19T03:14:07Z

Software still using that representation will overflow one second later . Modern platforms tend to use larger time values, but legacy file formats, older embedded devices and compatibility layers can still be plagued by the limitation. If your application has a long retention period or talks to older systems, test dates around this boundary now (not in 2038 when everyone will be busy pretending they saw it coming).

#Quick reference timestamps

These values are useful for tests, log inspection, and a quick sanity check. They are are shown in UTC.

Unix seconds	ISO 8601 UTC	Why it comes up
0	1970-01-01T00:00:00Z	The Unix epoch
86400	1970-01-02T00:00:00Z	One day after the epoch
1000000000	2001-09-09T01:46:40Z	The first 10-digit milestone
1700000000	2023-11-14T22:13:20Z	A handy modern example
2147483647	2038-01-19T03:14:07Z	Signed 32-bit maximum

#A reliable timestamp workflow

If you come across an unfamiliar time value, don't be tempted to guess by eye. you can check below 4 elements:

1. Epoch: What date is zero?
2. Unit: Is the value in seconds, milliseconds, microseconds or nano seconds?
3. Timezone: Is the input an instant in time, or a local date/time that needs a timezone?
4. Output contract: What does the next system expect, number, ISO 8601 string, seconds or milliseconds?

When those answers are obvious, converting timestamps is standard procedure. The math is done by the converter; you just have to preserve the meaning at the boundary.