Epoch Timestamp Converter
Convert Unix Timestamps to Dates and Back with Timezone Support
Convert between epoch timestamps and readable dates instantly. Supports multiple date formats, timezones, and both unix time to date and date to timestamp conversions.
Related developer tools
Understanding Time Formats
What is Unix Time?
Unix time (also known as POSIX time or epoch time) represents the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC, excluding leap seconds. It‘s widely used in computer systems for date and time representation.
What is Epoch Time?
Epoch time is essentially the same as Unix time. It refers to the point in time (January 1, 1970) from which time is measured. The epoch serves as a reference point for computer systems to calculate dates and times.
Milliseconds vs. Seconds
Unix timestamps can be represented in either seconds or milliseconds:
- Unix timestamp in seconds: 1620000000
- Unix timestamp in milliseconds: 1620000000000
Most systems use seconds, but languages like JavaScript use milliseconds internally.
Common Time Formats Compared
| Format | Example | Use Case |
|---|---|---|
| Unix Timestamp | 1620000000 | Programming, databases |
| ISO 8601 | 2021-05-03T00:00:00Z | International standard, APIs |
| RFC 2822 | Mon, 03 May 2021 00:00:00 +0000 | Email headers |
| Human Readable | May 3, 2021 | User interfaces |
Unix Epoch Reference
Everything a developer needs to work with epoch timestamps confidently — language snippets, format conversions, common gotchas, and example timestamps you can copy directly into your tests.
Get the Current Unix Timestamp in Any Language
The Unix epoch is a language-agnostic concept, but every runtime exposes it slightly differently. Here are current-timestamp snippets in the languages developers ask about most often.
JavaScript / TypeScript
// Seconds (Unix standard) Math.floor(Date.now() / 1000) // Milliseconds (JS default) Date.now() // Convert timestamp to Date new Date(timestamp * 1000)
Python
import time from datetime import datetime, timezone # Current epoch (float seconds) time.time() # Integer seconds int(time.time()) # Timezone-aware conversion datetime.fromtimestamp(ts, tz=timezone.utc)
Bash / Shell
# Current epoch date +%s # Epoch -> human (GNU date) date -d @1700000000 # Epoch -> human (BSD/macOS) date -r 1700000000 # Human -> epoch date -d "2026-01-01 00:00:00 UTC" +%s
SQL
-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::bigint;
SELECT to_timestamp(1700000000);
-- MySQL
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1700000000);
-- SQLite
SELECT strftime('%s', 'now');Go
import "time" // Current epoch in seconds time.Now().Unix() // Milliseconds time.Now().UnixMilli() // Epoch -> time.Time time.Unix(1700000000, 0)
Rust
use std::time::{SystemTime, UNIX_EPOCH};
let secs = SystemTime::now()
.duration_since(UNIX_EPOCH)
.unwrap()
.as_secs();Ruby
# Current epoch Time.now.to_i # Milliseconds (Time.now.to_f * 1000).to_i # Epoch -> Time Time.at(1700000000)
C# / .NET
// .NET 6+ — current epoch seconds DateTimeOffset.UtcNow.ToUnixTimeSeconds() // Milliseconds DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() // Epoch -> DateTimeOffset DateTimeOffset.FromUnixTimeSeconds(1700000000)
Java
// Java 8+ recommended Instant.now().getEpochSecond() Instant.now().toEpochMilli() // Epoch -> Instant Instant.ofEpochSecond(1700000000)
PHP
// Current epoch
time();
// Milliseconds
(int)(microtime(true) * 1000);
// Epoch -> human
date('Y-m-d H:i:s', 1700000000);Common Timestamp Formats Side by Side
One moment in time can be written in many ways. Picking the wrong format is one of the most common interoperability bugs in APIs. The reference timestamp below is 1700000000 — Tuesday, 14 November 2023, 22:13:20 UTC.
| Format | Example | When to use |
|---|---|---|
| Unix seconds | 1700000000 | Storage, databases, OS APIs, cron, JWT exp/iat |
| Unix milliseconds | 1700000000000 | JavaScript, Java, mobile SDKs, event streams |
| Unix microseconds | 1700000000000000 | High-frequency systems, distributed tracing |
| ISO 8601 (UTC) | 2023-11-14T22:13:20Z | REST/GraphQL APIs, logs, machine-readable |
| ISO 8601 (offset) | 2023-11-14T17:13:20-05:00 | Preserving local context (calendar events) |
| RFC 2822 | Tue, 14 Nov 2023 22:13:20 +0000 | Email headers (Date:), HTTP headers |
| RFC 3339 (subset of 8601) | 2023-11-14T22:13:20.000Z | Internet protocols requiring strict parsing |
| Locale (US human) | Nov 14, 2023, 10:13 PM | UI display only — never store this |
Gotchas That Bite Developers
Seconds vs. milliseconds — the #1 mistake
JavaScript's Date.now() returns milliseconds. Most other languages return seconds. If a date shows as 1970-01-20 when you expected today, you divided by 1000 too many times. If it shows as 50000+ AD, you multiplied. Always document whether your API uses seconds or milliseconds, and prefer ISO 8601 on the wire to avoid the question entirely.
Leap seconds
POSIX defines Unix time to ignore leap seconds — every day is exactly 86,400 seconds, even on the ~27 days in history when UTC actually had 86,401. For most applications this is invisible. For NTP servers, financial trading, or anything with sub-second SLAs, "smeared" clocks (Google, Amazon, Meta Time) distribute the leap second across hours so timestamps remain monotonic.
Daylight saving time (DST)
Unix timestamps are immune to DST because they are UTC. DST is a display concern. If a recurring event is "every Monday at 9 AM in New York," you must store it as a wall-clock time + IANA timezone (e.g. America/New_York), not as a Unix timestamp — otherwise the meeting will jump an hour twice a year.
The Year 2038 problem
A signed 32-bit integer overflows at 2147483647, which is 2038-01-19 03:14:07 UTC. Any code, embedded device, file format, or database column still using INT for timestamps will roll over to 1901. Use 64-bit integers everywhere — they overflow in the year 292,277,026,596 AD.
Negative timestamps
Timestamps before 1970-01-01 UTC are negative. They're valid in most modern libraries but many legacy systems treat them as errors or wrap around. If you're storing historical dates (birthdays, archives), prefer a date column over an epoch.
String "timestamps" vs. integers
Many APIs send epoch values as JSON strings ("1700000000") to avoid precision loss on 64-bit values in JavaScript, where numbers are IEEE-754 doubles. Always parse explicitly — silent string-to-number coercion has caused outages.
Notable Epoch Timestamps
Handy values to test boundary conditions in your code.
| Timestamp | Date (UTC) | Why it matters |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The Unix epoch itself |
| 1000000000 | 2001-09-09 01:46:40 | First 10-digit timestamp ("Unix billennium") |
| 1234567890 | 2009-02-13 23:31:30 | Memorable monotonic sequence — celebrated by Unix enthusiasts |
| 1500000000 | 2017-07-14 02:40:00 | Convenient round value for test fixtures |
| 2147483647 | 2038-01-19 03:14:07 | Year-2038 overflow boundary (signed 32-bit max) |
| -2208988800 | 1900-01-01 00:00:00 | NTP epoch offset (NTP counts from 1900, not 1970) |
Best Practices
- Store UTC, display local. Persist Unix timestamps or ISO 8601 with a Zsuffix; convert to the user's zone only at render time.
- Pick a precision and document it. Mixing seconds and milliseconds in the same codebase causes 1000× bugs that are silent in dev and catastrophic in production.
- Use IANA timezone names, not offsets. America/New_York survives DST changes; UTC-05:00doesn't.
- Use 64-bit integers. The 2038 cliff is closer than you think, and embedded devices ship with multi-decade lifespans.
- Validate input ranges. Reject timestamps that fall outside a sane window (e.g. 2000–2100 for booking systems) — most bad data comes from unit-confusion bugs upstream.
- Prefer ISO 8601 on the wire.It's human-readable, sorts lexicographically, self-documents timezone, and survives every JSON parser without precision loss.
Epoch timestamp FAQs
Common questions about Unix timestamps, epoch time, and how to use this converter.