How to Convert Unix Timestamps

Unix timestamps are how computers store and communicate time: a single number representing seconds since January 1, 1970. They appear in API responses, database records, log files, and JWT tokens. When you need to know what date 1711824000 actually is, you need a converter. A browser-based converter handles the math instantly and lets you go either direction (timestamp to date, date to timestamp).

What a Unix timestamp looks like

The difference between seconds and milliseconds is three extra zeros. A 10-digit number is in seconds; 13 digits is milliseconds. As of 2024, all seconds-based Unix timestamps are 10 digits and will remain so until November 2286.

How to convert timestamps

1. Enter a timestamp or date: paste a Unix timestamp to convert to a readable date, or enter a date to get the timestamp.
2. Check the format: the converter auto-detects seconds vs milliseconds based on the number length.
3. Read the result: see the date in your local timezone, UTC, and ISO 8601 format.

A brief history of Unix time

Unix time was first defined in the Unix Programmer's Manual published at Bell Labs in November 1971. The original epoch was January 1, 1971, but it was changed to January 1, 1970 shortly afterward and standardized in POSIX.1 (1988).

The choice of 1970 was arbitrary but practical: Unix was developed in 1969-1971, and starting the count near the OS's birth seemed reasonable. A 32-bit signed integer counting seconds from 1970 gave a range from December 1901 to January 2038, which the designers thought would be enough.

It is not. The "Year 2038 problem" (also called Y2K38) is the moment when 32-bit signed Unix timestamps overflow: 2147483647 seconds after the epoch, the next tick rolls over to a negative number that systems interpret as December 1901. Most modern systems migrated to 64-bit integer timestamps in the 2000s and 2010s, but some embedded devices, older databases, and legacy file formats still use 32-bit time and will need patches before 2038.

Unix time is now the de facto standard for representing time in computer systems. JSON APIs, database row timestamps, JWT expirations, blockchain block-times, IoT sensor readings: nearly all use the Unix epoch directly or indirectly.

Seconds, milliseconds, microseconds, nanoseconds

Different systems use different precisions:

• Seconds (10 digits in 2024): classic Unix time, POSIX standard, most APIs and databases
• Milliseconds (13 digits): JavaScript Date, Java System.currentTimeMillis(), many web APIs
• Microseconds (16 digits): PostgreSQL timestamp, Python datetime (after conversion)
• Nanoseconds (19 digits): Go time.UnixNano(), eBPF tracing, high-frequency trading systems

A 19-digit timestamp can confuse converters expecting milliseconds; double-check the source documentation when you see anomalous numbers.

Where you encounter timestamps

• API responses: most REST APIs return dates as Unix timestamps: "created_at": 1711824000
• JWT tokens: the iat (issued at) and exp (expiration) claims are Unix timestamps
• Database records: many databases store timestamps as integers for efficient sorting and comparison
• Log files: server logs often prefix entries with epoch timestamps
• Cron jobs: scheduling systems reference time in Unix format
• File system mtime/atime/ctime: Linux and macOS file metadata uses Unix time
• Blockchain block timestamps: every Bitcoin and Ethereum block has a Unix timestamp in its header
• Cookies and HTTP headers: Max-Age, If-Modified-Since often use epoch math indirectly

Timestamps in code

Quick conversion in common languages:

JavaScript:

new Date(1711824000 * 1000)            // From seconds (multiply by 1000)
new Date(1711824000000)                // From milliseconds
Math.floor(Date.now() / 1000)          // Current time in seconds
Date.now()                             // Current time in milliseconds

Python:

from datetime import datetime, timezone
datetime.fromtimestamp(1711824000, tz=timezone.utc)
datetime.now(timezone.utc).timestamp()  # Current time in seconds (float)

Bash:

date -u -d @1711824000                 # GNU date (Linux)
date -u -r 1711824000                  # BSD date (macOS)
date +%s                               # Current time in seconds

SQL (PostgreSQL):

SELECT TO_TIMESTAMP(1711824000);       -- Convert epoch to timestamp
SELECT EXTRACT(EPOCH FROM NOW());      -- Current epoch

Go:

time.Unix(1711824000, 0)               // From seconds
time.Now().Unix()                      // Current time in seconds

Timezone handling

This is where most timestamp bugs hide:

• Unix timestamps are always UTC. There is no such thing as a "local time" Unix timestamp. The number itself is absolute.
• Display timezone matters. The same timestamp 1711824000 displays as:
  • 2024-03-31 00:00:00 UTC
  • 2024-03-30 17:00:00 PDT (Los Angeles, UTC-7)
  • 2024-03-31 09:00:00 JST (Tokyo, UTC+9)
• DST transitions are tricky. A local time like "2024-03-10 02:30:00 EST" does not exist (clock skipped from 02:00 to 03:00). Converters handle this differently; some return an error, some round to 03:30, some shift to standard time.
• Leap seconds are ignored. Unix time pretends every minute has exactly 60 seconds. Real UTC inserts leap seconds occasionally (the last was 2016). For 99% of uses this is fine; for precision astronomy or atomic clocks it matters.

When sending timestamps in APIs, always use UTC seconds. When displaying to users, convert to their local timezone. The converter handles both directions.

Common pitfalls

• JavaScript Date() constructor takes milliseconds, not seconds: the #1 timestamp bug. new Date(1711824000) interprets the number as January 20, 1970 because JS reads it as milliseconds. You need new Date(1711824000 * 1000).
• Mixing up Unix time and Excel/Google Sheets date numbers: Excel uses a different epoch (December 30, 1899) and counts days, not seconds. Importing a Unix timestamp into a date column will display the wrong date.
• Negative timestamps: dates before January 1, 1970 are represented as negative Unix timestamps. Some converters and databases reject them; others handle them correctly.
• Year 2038 in legacy code: 32-bit signed integer timestamps overflow January 19, 2038 at 03:14:07 UTC. Most modern systems use 64-bit, but check embedded devices, old SQLite databases, and 32-bit OSes.
• Locale-dependent date parsing: "03/04/2024" is March 4 in US English, April 3 in UK English. Always pass timestamps (or ISO 8601 strings) between systems; never locale-formatted strings.
• Sub-second precision loss: storing a millisecond timestamp in a seconds-precision field loses the last 3 digits. Some APIs return both formats (created_at in seconds, created_at_ms in milliseconds) to avoid this.

Tips

• Multiply by 1000 for JavaScript: JS Date expects milliseconds, but most APIs return seconds. Forgetting to multiply is the most common timestamp bug.
• Always specify UTC: when converting, be explicit about timezone. "March 31 at midnight" is a different timestamp depending on whether you mean UTC, EST, or PST.
• Use ISO 8601 for display: once converted, format dates as 2024-03-31T00:00:00Z for unambiguous communication across timezones.
• Bookmark the converter: if you work with APIs or databases, you will convert timestamps often enough to want it one click away.
• Round-trip to verify: when in doubt, convert your timestamp to a date, then convert the date back to a timestamp. If you get the same number, your understanding is correct.
• Watch the number of digits: 10 = seconds, 13 = milliseconds, 16 = microseconds, 19 = nanoseconds. If your math is off by a factor of 1000 or 1000000, you have a precision mismatch.

Privacy

The Unix timestamp converter runs entirely in your browser. The timestamps and dates you enter never leave your device. This matters because timestamps can be sensitive: they may be from log files revealing internal infrastructure timing, JWT tokens with embedded user/session info, internal API debugging that should not be shared with third parties. Cloud timestamp converters may log inputs for "improvement" purposes; a browser-only converter has zero exposure.

Browser-based conversion also works offline once the page loads, and is fast enough that you can drop a timestamp into the field and see the date in the same moment.