Convert TIMESTAMP to DATE Online

Upload a TIMESTAMP file and convert it to DATE in seconds—simple, fast, and easy to use directly in your browser.

Get current epoch in your language

// Current epoch (seconds)
Math.floor(Date.now() / 1000)

// Milliseconds
Date.now()

// Parse epoch
new Date(1700000000 * 1000)

How to Convert Unix Timestamp to Date Online

  1. Paste Your Unix Timestamp: Type or paste the epoch value into the input field — 1748332800 for seconds, 1748332800000 for milliseconds, 1748332800000000 for microseconds. Click "Now" to insert the current timestamp, or paste one timestamp per line for batch conversion.
  2. Confirm the Precision: The converter auto-detects based on digit count (10 = seconds, 13 = milliseconds, 16 = microseconds, 19 = nanoseconds), but you can override it from the precision selector if your source uses an unusual width. Decimal values like 1748332800.123 are accepted and preserve sub-second precision.
  3. Pick a Time Zone and Format (Optional): Results display in UTC and your browser's local zone by default. Switch to any IANA zone (America/New_York, Europe/London, Asia/Tokyo) or change the output format between ISO 8601 (2026-05-27T08:00:00Z), RFC 2822, or local-style strings (MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD).
  4. Copy or Share the Result: The output panel shows the converted date in every selected format plus a relative-time hint ("3 hours ago", "in 2 days"). Click any value to copy it to your clipboard. Conversion runs entirely client-side — nothing is sent to a server.

Why Convert Unix Timestamps to Dates?

A Unix timestamp (also called epoch time or POSIX time) is the count of seconds since 1970-01-01 00:00:00 UTC — a compact, time-zone-independent way to represent a moment. They appear in API payloads, database columns, log lines, JWT claims, and file metadata, but a number like 1748332800 is unreadable until you turn it back into a date. Day-to-day situations that need this conversion:

  • Debugging API responses — REST and GraphQL APIs from Stripe, GitHub, Twilio, Slack, and AWS routinely return created_at, updated_at, and expires_at as Unix seconds. Paste the value here to see exactly when a webhook fired, a token issued, or a charge settled — especially useful when chasing race conditions or rate-limit windows.
  • Inspecting JWT claims — JSON Web Tokens carry iat (issued at), nbf (not before), and exp (expiration) as Unix seconds per RFC 7519. Decode the token in the JWT Decoder, then paste each numeric claim here to check whether the token is still valid and how much lifetime remains.
  • Reading log files — Many server logs, syslog entries, and Kubernetes events store timestamps as epoch seconds or milliseconds for compactness. Converting them lets you correlate events with on-call pages, deploys, or user-reported incidents in real wall-clock time.
  • Database forensics — MySQL INT columns, MongoDB created fields, and DynamoDB TTL attributes commonly store epoch seconds. A quick conversion confirms whether a row's timestamp matches the intended window without writing a FROM_UNIXTIME() query against production.
  • Scheduled-job and cron verification — When you compute a future epoch for a Kubernetes CronJob, an AWS EventBridge rule, or a setTimeout deadline, paste it here to confirm it lands at the intended local time (and the right side of any DST cliff).
  • Security and audit timelines — SIEM exports, CloudTrail events, and OAuth refresh records use epoch values; building an incident timeline goes faster when you can convert hundreds of values in batch instead of one at a time.

Need the reverse direction? Use the Date to Unix Timestamp converter to turn human dates back into epoch values.

Seconds vs Milliseconds vs Microseconds — Digit-Count Cheat Sheet

The single most common bug is misidentifying precision: passing 1748332800000 (ms) to a function that expects seconds gives a date around the year 57380. Use digit count to sanity-check.

Digits Unit Example Common in
10 Seconds 1748332800 Unix date +%s, MySQL UNIX_TIMESTAMP(), Stripe API, JWT exp/iat, Linux file mtimes
13 Milliseconds 1748332800000 JavaScript Date.now(), Java System.currentTimeMillis(), Kafka timestamps, MongoDB drivers
16 Microseconds 1748332800000000 Python time.time_ns() / 1000, Chrome trace events, some PostgreSQL TIMESTAMP ranges
19 Nanoseconds 1748332800000000000 Go time.UnixNano(), Prometheus, OpenTelemetry traces, eBPF

These boundaries are stable until roughly the year 2286, when current 10-digit second timestamps will roll into 11 digits. Until then, the digit-count rule is reliable for any timestamp within a century of "now."

Code Snippets — Convert Epoch to Date in Common Languages

If you want to do the same conversion in code instead of in a browser, the canonical recipes are:

Language / Tool Snippet (seconds → date)
JavaScript new Date(1748332800 * 1000).toISOString()
Python datetime.datetime.fromtimestamp(1748332800, tz=datetime.timezone.utc).isoformat()
Bash (GNU) date -u -d @1748332800 +"%Y-%m-%dT%H:%M:%SZ"
macOS (BSD date) date -ur 1748332800 +"%Y-%m-%dT%H:%M:%SZ"
PowerShell [DateTimeOffset]::FromUnixTimeSeconds(1748332800).UtcDateTime
MySQL SELECT FROM_UNIXTIME(1748332800);
PostgreSQL SELECT to_timestamp(1748332800);
Go time.Unix(1748332800, 0).UTC().Format(time.RFC3339)
Java Instant.ofEpochSecond(1748332800).toString()
Excel =(A1/86400)+DATE(1970,1,1) (format cell as date/time)

Frequently Asked Questions

Why does my JavaScript Date show 1970 when I pass a Unix timestamp?

new Date() in JavaScript expects milliseconds since the epoch, but most APIs return seconds. A 10-digit value passed straight in is interpreted as milliseconds since 1970, putting you somewhere in late January 1970. Multiply by 1000 first: new Date(seconds * 1000). This is the most reported timestamp bug on Stack Overflow.

How do I tell whether my timestamp is seconds, milliseconds, or microseconds?

Count the digits. For any moment between 2001 and 2286, seconds have 10 digits, milliseconds 13, microseconds 16, and nanoseconds 19. A bare 1748332800 from a JSON payload is almost certainly seconds; 1748332800000 is almost certainly milliseconds. The converter detects this automatically, but the rule is easy to spot-check yourself.

What is the Year 2038 problem and does it affect this converter?

Per Wikipedia's Year 2038 article, systems that store Unix time in a signed 32-bit integer overflow at 2,147,483,647 seconds — 03:14:07 UTC on 19 January 2038 — wrapping to a negative value that gets interpreted as 13 December 1901. This converter uses JavaScript Number, which is a 64-bit float with safe-integer range up to 2^53, so it handles dates billions of years out without overflow. The risk lives in legacy embedded systems and old binaries, not in modern browsers or 64-bit OSes.

Do Unix timestamps account for leap seconds?

No. Per the POSIX definition and confirmed by NIST, Unix time counts seconds linearly and ignores leap seconds. UTC has added 27 leap seconds since 1972 (the TAI−UTC offset is 37 seconds as of 2026, including the initial 10-second offset), so a Unix timestamp can drift from "true" UTC by that cumulative amount at the moment of a leap second. For everyday work — logging, billing, scheduling — this is invisible; for GPS, telescope pointing, or financial settlement audits it matters and you should consult an authoritative source like USNO.

Can I convert timestamps with decimals or fractional seconds?

Yes. Values like 1748332800.123 are read as seconds with millisecond precision and the converter preserves the fraction in the output. Some Python codebases (time.time()) and many monitoring systems emit fractional epoch values; you don't need to strip the decimal.

What does a negative Unix timestamp represent?

Times before the 1970-01-01 epoch. -86400 = 1969-12-31 00:00:00 UTC, -2208988800 = 1900-01-01 UTC. Negative timestamps work in most languages (JavaScript, Python, Java, Go, modern C) but some older C libraries and 32-bit unsigned time_t implementations reject them — useful to know if you're targeting embedded firmware.

Will the same timestamp show different dates in different time zones?

Yes — that's the point of a Unix timestamp. The integer value is identical worldwide, but rendering it for "Sydney" vs "Los Angeles" gives times 17–19 hours apart depending on DST. The converter shows UTC plus your browser-detected local zone by default; switch to an IANA zone (America/New_York, Europe/Berlin, Asia/Kolkata) to see how the same instant appears elsewhere.

Why does the same JWT show "expired" on my laptop but "valid" on the server?

JWT exp is a Unix timestamp in seconds and is compared against the validator's current clock. If the two clocks disagree by more than the allowed leeway (often 30–60 seconds), one side rejects a token the other accepts. Paste the exp value here, compare against your system time, and check NTP sync on the lagging host — clock skew is the cause more often than the token itself.

Can I batch-convert many timestamps at once?

Yes. Paste one timestamp per line in the input field and each line is converted independently in the output panel. Useful when triaging a log slice or migrating a column of INT timestamps to DATETIME — you can paste hundreds at once and copy the converted column back out.

Does this converter work offline?

Yes. After the page loads once, conversion runs entirely in client-side JavaScript with no further network requests. You can disconnect, open the bookmarked URL from cache, and keep converting — useful on planes, in air-gapped environments, or while debugging connectivity itself.

Related XConvert tools: Date to Unix Timestamp · JWT Decoder · JSON Formatter · CSV to JSON · Base64 Encoder