Unit ToolsΒ·5 min

How to Convert Unix Timestamps to Dates (and Back)

Convert Unix epoch seconds to human-readable dates in any timezone. With practical examples.

What is a Unix timestamp?

A Unix timestamp (also called Unix time, POSIX time, or epoch time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, not counting leap seconds. That moment is called the Unix epoch.

For example:

  • 0 = 1970-01-01 00:00:00 UTC (the epoch)
  • 1,000,000,000 = 2001-09-09 01:46:40 UTC (the "billennium")
  • 1,234,567,890 = 2009-02-13 23:31:30 UTC
  • 1,700,000,000 = 2023-11-14 22:13:20 UTC
  • 2,000,000,000 = 2033-05-18 03:33:20 UTC

Unix timestamps are everywhere in computing:

  • Databases: PostgreSQL, MySQL, and SQLite all store time internally as Unix timestamps (or with reference to them).
  • File systems: ext4, NTFS, and APFS store file mtimes as Unix timestamps.
  • APIs: JSON APIs commonly return timestamps as integers, e.g., `"created_at": 1700000000`.
  • Logs: Most logging systems emit timestamps in Unix format.
  • Programming languages: PHP, Python, JavaScript, Go, Rust, and Java all have built-in support.

The reason Unix timestamps are popular: they are simple integers, easy to compare, easy to sort, timezone-independent (they always refer to UTC), and trivial to store. They also make arithmetic simple β€” to find the duration of two events, subtract their timestamps.

How to read a Unix timestamp

The mental model: imagine a clock that started ticking at midnight UTC on January 1, 1970, and has been counting seconds ever since. The Unix timestamp is the reading on that clock.

``` 1 minute = 60 seconds 1 hour = 3,600 seconds 1 day = 86,400 seconds (24 Γ— 60 Γ— 60) 1 week = 604,800 seconds (7 Γ— 86,400) 1 year β‰ˆ 31,536,000 seconds (365.25 Γ— 86,400, average) 1 decade β‰ˆ 315,360,000 seconds ```

A few mental anchors:

  • 1,000,000,000 = 2001-09-09. The Unix billennium β€” the first second with 10 digits.
  • 1,500,000,000 = 2017-07-14. The "1.5 billion" mark.
  • 2,000,000,000 = 2033-05-18. The first 2-billion-second date.
  • The 2038 problem: 32-bit signed integers overflow at 2,147,483,647, which is 2038-01-19 03:14:07 UTC. After that, 32-bit Unix timestamps wrap around to negative values.

The exact conversion formulas

Timestamp to human date

``` human_date = epoch + timestamp seconds (UTC) local_date = human_date converted to local timezone ```

In most programming languages:

```python import datetime ts = 1700000000 utc = datetime.datetime.fromtimestamp(ts, tz=datetime.timezone.utc) # 2023-11-14 22:13:20+00:00 local = datetime.datetime.fromtimestamp(ts) # depends on your system timezone ```

```js const ts = 1700000000; const date = new Date(ts * 1000); // JS uses milliseconds // 2023-11-14T22:13:20.000Z ```

Human date to timestamp

``` timestamp = (date - epoch) in seconds ```

```python import datetime d = datetime.datetime(2023, 11, 14, 22, 13, 20, tzinfo=datetime.timezone.utc) ts = int(d.timestamp()) # 1700000000 ```

```js const d = new Date("2023-11-14T22:13:20Z"); const ts = Math.floor(d.getTime() / 1000); // 1700000000 ```

Common timezone offsets (relative to UTC)

When working with timestamps, you often need to display in a specific timezone:

| Timezone | Abbreviation | Offset | Example cities | |--------------------------------|--------------|-----------------|----------------------------------| | Coordinated Universal Time | UTC | 0 | London (winter), Reykjavik | | Eastern Standard Time | EST | UTCβˆ’5 | New York (winter) | | Eastern Daylight Time | EDT | UTCβˆ’4 | New York (summer) | | Pacific Standard Time | PST | UTCβˆ’8 | Los Angeles (winter) | | Pacific Daylight Time | PDT | UTCβˆ’7 | Los Angeles (summer) | | Central European Time | CET | UTC+1 | Paris (winter), Berlin | | Central European Summer Time | CEST | UTC+2 | Paris (summer), Berlin | | Japan Standard Time | JST | UTC+9 | Tokyo | | China Standard Time | CST | UTC+8 | Beijing, Shanghai | | India Standard Time | IST | UTC+5:30 | Mumbai, Delhi | | Australian Eastern Standard | AEST | UTC+10 | Sydney (winter) | | Australian Eastern Daylight | AEDT | UTC+11 | Sydney (summer) |

Note that some countries (India, China) observe a single year-round offset with no daylight saving.

Method 1: Use UtilBoxx's Time Converter (Recommended)

The fastest, most private, and most accurate way to convert Unix timestamps in your browser is the UtilBoxx Time Converter. It supports both seconds and milliseconds, displays in any timezone, and shows the corresponding ISO 8601 date, UTC, and local time. Everything runs in your browser β€” no server, no upload, no logs.

How to use it:

  1. Go to utilboxx.com/en/tools/unit/time
  2. Type a Unix timestamp (in seconds) or a date string
  3. The converted value appears instantly
  4. Switch between timezones with one click
  5. Copy the result

Why we recommend this method:

  • 100% free, no signup, no email, no ads
  • Privacy-first: nothing leaves your browser
  • Bidirectional: timestamp ↔ date in either direction
  • Multi-timezone: see your timestamp in UTC, your local zone, or any zone
  • Handles milliseconds for JavaScript-style timestamps
  • Works on any device with a browser

If you work with APIs, logs, or databases that store time as Unix timestamps, this tool pays for itself the first week.

Method 2: Python (datetime module)

Python's `datetime` module is the canonical tool for timestamp conversion. The two key functions are `fromtimestamp()` and `timestamp()`.

```python import datetime from zoneinfo import ZoneInfo

# Convert timestamp to date (UTC) ts = 1700000000 utc_date = datetime.datetime.fromtimestamp(ts, tz=datetime.timezone.utc) # 2023-11-14 22:13:20+00:00

# Convert timestamp to date in a specific timezone ny_tz = ZoneInfo("America/New_York") ny_date = datetime.datetime.fromtimestamp(ts, tz=ny_tz) # 2023-11-14 17:13:20-05:00

# Convert date to timestamp d = datetime.datetime(2023, 11, 14, 22, 13, 20, tzinfo=datetime.timezone.utc) ts = int(d.timestamp()) # 1700000000

# Now: current timestamp now_ts = int(datetime.datetime.now(tz=datetime.timezone.utc).timestamp())

# Format date as ISO 8601 print(utc_date.isoformat()) # 2023-11-14T22:13:20+00:00 ```

Python 3.9+ also has the simpler `datetime.fromtimestamp(ts, tz=UTC)` form, and the `zoneinfo` module (replacing the older `pytz`) makes timezone handling easy.

Method 3: Bash / command line

The `date` command on macOS and Linux can both parse and emit Unix timestamps.

```bash # Convert a Unix timestamp to a human-readable date (macOS / BSD) date -r 1700000000 # Tue Nov 14 22:13:20 UTC 2023

# Convert a Unix timestamp (Linux / GNU date) date -d @1700000000 # Tue Nov 14 22:13:20 UTC 2023

# Get the current Unix timestamp date +%s # 1700000000 (or whatever it is now)

# Convert a date string to a Unix timestamp (GNU) date -d "2023-11-14 22:13:20 UTC" +%s # 1700000000

# Convert a date string to a Unix timestamp (macOS) date -j -f "%Y-%m-%d %H:%M:%S" "2023-11-14 22:13:20" +%s # 1700000000

# Display in a specific timezone TZ="America/New_York" date -d @1700000000 # Tue Nov 14 17:13:20 EST 2023 ```

The syntax differs between macOS and Linux. On macOS, `-r` reads a timestamp; on Linux, `-d @...` reads a timestamp and `-d "..."` parses a date. For scripting, the GNU form (Linux) is friendlier; the macOS form is more cumbersome but works.

Method 4: JavaScript (in the browser or Node.js)

JavaScript uses milliseconds for Unix timestamps, not seconds. Multiply by 1,000 going from seconds to milliseconds.

```js // Current timestamp in milliseconds const now = Date.now(); // e.g., 1700000000000

// Convert seconds to milliseconds and create a Date const ts = 1700000000; const date = new Date(ts * 1000); // 2023-11-14T22:13:20.000Z

// Display in a specific timezone using Intl console.log(date.toLocaleString("en-US", { timeZone: "America/New_York" })); // 11/14/2023, 5:13:20 PM

// Display as ISO 8601 console.log(date.toISOString()); // 2023-11-14T22:13:20.000Z

// Convert date to timestamp (seconds) const d = new Date("2023-11-14T22:13:20Z"); const ts2 = Math.floor(d.getTime() / 1000); // 1700000000

// Parse various formats new Date("2023-11-14"); // midnight UTC new Date("2023-11-14T22:13:20Z"); // 22:13:20 UTC new Date(1700000000 * 1000); // from milliseconds new Date("Nov 14, 2023 22:13:20");// locale-dependent parsing (avoid!) ```

JavaScript's `Date` object is famously quirky. For serious work, use a library like `date-fns`, `Luxon`, or `Day.js`. For quick conversions, the built-in `Date` is fine.

Common questions

Why is the Unix epoch January 1, 1970?

It is the date the Unix operating system was first implemented. Ken Thompson and Dennis Ritchie chose it arbitrarily when designing Unix at Bell Labs in 1969-1970. There is no astronomical or mathematical reason; it was simply the start of the decade they were working in. Several other systems have chosen different epochs: Windows FILETIME uses January 1, 1601; macOS HFS+ used January 1, 1904; GPS uses January 6, 1980.

What is the 2038 problem?

The 2038 problem (also called Y2K38) is the 32-bit signed integer overflow that occurs on January 19, 2038, at 03:14:07 UTC. A 32-bit signed integer can hold values up to 2,147,483,647. One second later, it overflows to βˆ’2,147,483,648, which is interpreted as 1901-12-13 20:45:52 UTC. Any system still using 32-bit Unix timestamps (mostly embedded devices, older databases, and some file systems) will break unless updated.

The fix is straightforward: switch to 64-bit integers, which extend the Unix timestamp range by 290 billion years. Most modern systems have already done this; the problem is mainly with legacy and embedded systems.

Are Unix timestamps in seconds or milliseconds?

It depends on the language:

  • Seconds: C, Python, Go, Rust, Java (traditionally), shell, SQL
  • Milliseconds: JavaScript, Java (java.time.Instant), some databases

JavaScript is the major outlier with milliseconds, which leads to bugs when JavaScript code is mixed with code from other languages. Always clarify the unit. The UtilBoxx converter handles both with a single toggle.

How do leap seconds affect Unix timestamps?

Strictly speaking, Unix timestamps ignore leap seconds. They count every second as if there were exactly 86,400 per day. Real-world UTC has occasional leap seconds (added to keep atomic time aligned with Earth's rotation), but Unix time does not include them. This means Unix time gradually drifts from UTC by a fraction of a second every few years.

In practice, this rarely matters for application code. NTP (Network Time Protocol) handles the discrepancy. If you need strict TAI or atomic time, Unix timestamps are not the right tool.

What is "ISO 8601"?

ISO 8601 is an international standard for date and time formats, designed to be unambiguous and machine-readable. Examples:

  • `2023-11-14` (date only)
  • `2023-11-14T22:13:20` (date and time, no timezone)
  • `2023-11-14T22:13:20Z` (UTC, "Z" = "Zulu time")
  • `2023-11-14T22:13:20+05:00` (with timezone offset)
  • `2023-11-14T22:13:20.123Z` (with milliseconds)
  • `20231114T221320Z` (compact form, no separators)

ISO 8601 is the recommended format for storing and exchanging date/time values because it sorts lexicographically and parses unambiguously. Most APIs use it.

How do I get the current Unix timestamp?

In every major language:

```bash # bash date +%s ```

```python import time time.time() # 1700000000.123 (float, with fractional seconds) int(time.time()) # 1700000000 (integer seconds) ```

```js Date.now() / 1000 // 1700000000.123 Math.floor(Date.now() / 1000) // 1700000000 ```

Conclusion

Unix timestamps are the universal language of time in computing. They are simple integers, easy to compare, easy to store, and timezone-independent. The epoch is January 1, 1970, and timestamps count seconds since then.

For occasional conversions, the UtilBoxx Time Converter is private, free, and works offline once loaded. For batch or scripted work, Python's `datetime` or the bash `date` command handle any volume of data. For interactive work, JavaScript's `Date` is built into every browser.

The mental shortcut: 1,000,000,000 = 2001 (Unix billennium), 1,500,000,000 = 2017, and 2,000,000,000 = 2033. With these anchors, you can estimate the year of any 10-digit timestamp in your head. And remember: in 12 years, the 2038 problem arrives, so audit your 32-bit timestamps now.