Java With Us

Epoch Timestamp ↔ Date Converter

Convert Unix timestamps to human-readable dates, and get ready-to-paste java.time snippets.

Now: …

ISO 8601 (UTC) —
UTC —
Selected TZ —
Relative —
Java snippet (java.time) 
// Loading…

What is a Unix timestamp?

A Unix timestamp (also called epoch) is the number of seconds (or milliseconds, microseconds, nanoseconds) elapsed since 1970-01-01T00:00:00 UTC. It's the universal format for machine-readable time, stored everywhere from log files to database columns to JWT tokens.

Java 8+: use java.time, not java.util.Date

The modern Java time API (java.time, introduced in Java 8) is thread-safe, immutable, and covers every time-zone and calendar concern correctly. Key classes:

  • Instant — a point on the timeline in UTC, with nanosecond precision. This is what you store in a database for "when did it happen".
  • ZonedDateTime — an Instant + a time zone. Use for rendezvous or anything tied to a real-world location.
  • LocalDateTime — a wall clock date-time without any time-zone attached. Never store one for events that cross zones.
  • LocalDate — just a calendar date, no time.

Epoch → Instant

Instant i1 = Instant.ofEpochSecond(1713699000);
Instant i2 = Instant.ofEpochMilli(1713699000_000L);
Instant i3 = Instant.now();

Instant → Epoch

long secs   = instant.getEpochSecond();
long millis = instant.toEpochMilli();

Converting to a specific time zone

ZonedDateTime ny = instant.atZone(ZoneId.of("America/New_York"));
// Display with a pattern
String formatted = DateTimeFormatter
    .ofPattern("yyyy-MM-dd HH:mm:ss z", Locale.US)
    .format(ny);
// 2024-04-21 06:30:00 EDT

Parsing a date string

Instant fromIso = Instant.parse("2026-04-21T10:30:00Z");

LocalDateTime ldt = LocalDateTime.parse(
    "2026-04-21T10:30:00",
    DateTimeFormatter.ISO_LOCAL_DATE_TIME);

ZonedDateTime zdt = ZonedDateTime.parse("2026-04-21T10:30:00+02:00[Europe/Paris]");

Why you should always store UTC

Store timestamps as epoch / Instant in the database and at API boundaries. Convert to a user-facing zone only when rendering. This removes every daylight-saving and tz-database update headache.

Common pitfalls

  • Mixing seconds and milliseconds — a timestamp of "1713" either means 1970 or 1970… there's no way to know without the unit.
  • Using new Date(long) with a seconds value — it expects milliseconds and you'll get a date in 1970.
  • Storing LocalDateTime in a database for cross-TZ events — the zone is lost.
  • Applying ZoneId.of("CET") expecting it to always be UTC+1 — it observes daylight saving. Use ZoneOffset.ofHours(1) for a fixed offset.