Unix Timestamp Converter

Convert a Unix epoch timestamp into a human-readable date in any timezone, and convert a date back into an epoch value. The converter handles seconds, milliseconds, microseconds and nanoseconds, works with dates before 1970, and understands daylight saving — including the two edge cases that quietly corrupt most conversions.

It is built for the situation Java developers actually hit: you have pulled a bare number out of a log line or a database column and you need to know what moment it represents, in which timezone, and how to reproduce that conversion in code. Every value you load also generates the matching java.time snippet, so you can paste it straight into your project.

What this timestamp converter does

• Detects the unit automatically — paste 10, 13, 16 or 19 digits and it reads them as seconds, milliseconds, microseconds or nanoseconds. You can override the guess at any time.
• Converts in both directions — epoch to date, and date back to epoch, with both inputs live on the same screen.
• Any IANA timezone — every zone your browser knows, including half-hour and quarter-hour offsets such as Asia/Kolkata (+05:30), Asia/Kathmandu (+05:45) and Pacific/Chatham (+12:45).
• Daylight saving aware — it tells you when a local time never happened or happened twice, instead of silently picking one.
• Live clock mode — follow the current time and read it across several timezones at once, as a world clock.
• Java code for every value — Instant, ZonedDateTime, formatting and parsing, legacy Date interop, Spring Boot and JPA configuration, plus the equivalent SQL in five databases.
• Bulk conversion — paste a whole column from a log or a spreadsheet and copy the results out as CSV.
• Completely private — nothing you paste leaves your browser.

Seconds, milliseconds, microseconds or nanoseconds?

This is the single most common mistake when reading a timestamp. Unix time counts seconds since 1 January 1970 UTC, but almost every platform stores a different precision, and a bare number carries no unit.

• Seconds — 10 digits today, e.g. 1700000000. Used by date +%s, PostgreSQL EXTRACT(EPOCH ...), JWT exp and iat claims, and most REST APIs.
• Milliseconds — 13 digits, e.g. 1700000000123. Used by System.currentTimeMillis(), java.util.Date, JavaScript Date.now(), Kafka record timestamps and MongoDB.
• Microseconds — 16 digits. Common in PostgreSQL internals and Python datetime.
• Nanoseconds — 19 digits. Used by System.nanoTime-style clocks, Go, and time-series stores such as InfluxDB and Prometheus.

The quickest check: read the value as seconds. If you land somewhere in 1970, it was milliseconds. If you land in the far future, you read milliseconds as seconds.

Converting epoch timestamps in Java

An epoch value is a point on the timeline, which in java.time is an Instant. It has no calendar and no timezone until you attach one:

long epochSeconds = 1700000000L;

Instant instant = Instant.ofEpochSecond(epochSeconds);
ZonedDateTime zdt = instant.atZone(ZoneId.of("Asia/Kolkata"));

System.out.println(instant); // 2023-11-14T22:13:20Z
System.out.println(zdt);     // 2023-11-15T03:43:20+05:30[Asia/Kolkata]

For milliseconds — which is what System.currentTimeMillis() and java.util.Date give you — use Instant.ofEpochMilli() instead.

Converting a date back to an epoch timestamp

This is the direction that trips people up. A LocalDateTime cannot become an epoch value on its own, because it has no timezone: 14:30 on a given date is a different moment in London than in Tokyo. You must say where it happened.

LocalDateTime local = LocalDateTime.of(2023, 11, 15, 3, 43, 20);

ZonedDateTime zdt = local.atZone(ZoneId.of("Asia/Kolkata"));
long epochSeconds = zdt.toEpochSecond();            // 1700000000
long epochMillis  = zdt.toInstant().toEpochMilli(); // 1700000000000

Why the same timestamp shows a different time on two machines

A java.util.Date holds nothing but epoch milliseconds. Its toString() renders that value in the JVM default timezone, which is why the same object prints one time on your laptop and another on the server. Nothing about the data changed; only the rendering did.

Three habits remove the whole class of bug:

• Store instants as Instant (or as UTC), never as a local date-time.
• Avoid ZoneId.systemDefault() in server code unless you genuinely mean "whatever this machine is set to". It is the reason tests pass locally and fail in CI.
• Set spring.jpa.properties.hibernate.jdbc.time_zone=UTC so Hibernate writes timestamps to the database in UTC regardless of the JVM zone.

Daylight saving: the two cases that break conversions

Converting an epoch value to a date is always unambiguous. Converting a local date and time back to an epoch value is not, twice a year:

• The gap. When clocks spring forward, an hour of local time never exists. In America/New_York on 10 March 2024 there is no 02:30 — the clock jumps from 01:59:59 to 03:00:00. Java resolves this by moving the time forward by the length of the gap; this converter tells you it happened rather than hiding it.
• The overlap. When clocks fall back, an hour repeats. In America/New_York on 3 November 2024, 01:30 occurs twice: once at −04:00 and again at −05:00. atZone() silently picks the earlier one. If you need the other, ask for it with withLaterOffsetAtOverlap(). The converter shows both and lets you choose.

Zones without daylight saving, such as Asia/Kolkata and UTC, never hit either case — one good reason to keep stored timestamps in UTC.

Timestamps worth knowing

• 0 — 1 January 1970, 00:00:00 UTC. The epoch itself.
• 946684800 — 1 January 2000. Y2K.
• 2147483647 — 19 January 2038, 03:14:07 UTC. The largest value a signed 32-bit time_t can hold; one second later it wraps to 1901. Java is safe because it uses a 64-bit long, but C libraries and older embedded systems are not.
• 253402300799 — 31 December 9999, the practical ceiling for many database timestamp columns.
• 9007199254740991 ms — Number.MAX_SAFE_INTEGER, where JavaScript stops counting exactly.

Negative values are valid and represent dates before 1970. The converter handles them, which most online converters do not.

Frequently asked questions

Is my data sent anywhere?

No. The converter is entirely client-side. Every timestamp you paste is converted by JavaScript running in your own browser. There is no server call, no logging and no storage, so it also keeps working after the page has loaded even if you go offline.

How do I know if my number is in seconds or milliseconds?

Count the digits. A present-day timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. The converter detects this automatically, and you can override it if the value is unusual. A quick sanity check: if you read a value as seconds and land in 1970, it was milliseconds.

Why does the same timestamp print a different time on my machine and on the server?

Because java.util.Date and LocalDateTime.now() use the JVM default timezone, which differs between your laptop and the server. The epoch value itself is identical - only the rendering changes. Store instants as Instant or as UTC, and set the zone explicitly when you display them.

How do I convert epoch seconds to a date in Java?

Instant.ofEpochSecond(epochSeconds) gives you the point on the timeline, then .atZone(ZoneId.of("Asia/Kolkata")) attaches a timezone so you can read the wall clock. For milliseconds use Instant.ofEpochMilli(). The Java tab in the tool generates this code for whatever value you have loaded.

Why can a LocalDateTime not be converted to epoch seconds on its own?

A LocalDateTime has no timezone, so 14:30 on a given date describes a different moment in London than in Tokyo. You have to supply a zone with .atZone(ZoneId.of(...)) or an offset with .toInstant(ZoneOffset.of(...)) before an epoch value exists.

What happens to timestamps that fall inside a daylight saving change?

Two things can go wrong. When clocks spring forward, an hour of local time never happens, so that reading has no epoch value. When clocks fall back, an hour repeats, so a reading maps to two different epoch values. The converter flags both cases and, for the repeated hour, lets you pick either occurrence.

What is the year 2038 problem?

A signed 32-bit time_t runs out at 2147483647 seconds, which is 19 January 2038 at 03:14:07 UTC. One second later it wraps to 1901. Java is unaffected because it uses a 64-bit long, but C libraries, some databases and older embedded systems still are.

Can I convert a whole column of timestamps at once?

Yes. Open "Convert a whole column at once", paste one value per line and press Convert. Epoch numbers and date strings can be mixed in the same paste, and the results can be copied out as CSV.

More developer tools

Other free, client-side tools on javahandson.com: JSON Formatter & Validator, application.properties ↔ application.yml Converter, MCP Config Generator & Validator and the Spring AI Token Counter.