Unix Timestamp Converter

Convert Unix timestamps to human-readable dates and vice versa. View the current Unix time and convert across 8 timezones.

Current Unix Timestamp
Unix Timestamp

Frequently Asked Questions

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 (the "Unix epoch"), not counting leap seconds. It is a standard way to represent a point in time as a single integer, regardless of timezone. For example, 1704067200 represents 2024-01-01 00:00:00 UTC.
Unix timestamps are traditionally in seconds (10 digits for current dates). JavaScript's Date.now() and many APIs return milliseconds (13 digits). You can tell which you have by the magnitude: a 10-digit number is seconds, a 13-digit number is milliseconds. To convert: divide milliseconds by 1000 to get seconds, multiply seconds by 1000 to get milliseconds. This tool auto-detects both formats.
On 19 January 2038 at 03:14:07 UTC, 32-bit signed integer Unix timestamps will overflow (reach 2³¹ - 1 = 2,147,483,647). Systems storing timestamps in 32-bit integers will wrap around to a large negative number, interpreted as 13 December 1901. Modern 64-bit systems are not affected — a 64-bit timestamp can represent dates billions of years into the future. Most modern systems and databases have migrated to 64-bit timestamps, but legacy embedded systems may still be vulnerable.
UTC (Coordinated Universal Time) is the global time standard. Unix timestamps are always in UTC — they have no timezone. When you display a timestamp as a human-readable date, you apply a timezone offset to get the local time. For example, timestamp 1704067200 is always 2024-01-01 00:00:00 UTC — but it is 2023-12-31 19:00:00 in New York (UTC-5) and 2024-01-01 09:00:00 in Tokyo (UTC+9).
JavaScript: Math.floor(Date.now() / 1000) (seconds) or Date.now() (milliseconds). PHP: time() (seconds) or microtime(true) (float seconds). Python: import time; int(time.time()). MySQL: UNIX_TIMESTAMP(). PostgreSQL: EXTRACT(EPOCH FROM NOW()). Bash: date +%s. Go: time.Now().Unix(). Java: System.currentTimeMillis() / 1000.
ISO 8601 is an international date/time format standard. The most common form is YYYY-MM-DDTHH:MM:SSZ where T separates date and time, and Z means UTC. Example: 2024-01-01T00:00:00Z. Unix timestamps can be converted to ISO 8601 and back. ISO 8601 is used in APIs, JSON, and HTML datetime attributes because it is unambiguous and sortable. JavaScript: new Date(ts * 1000).toISOString().
Best practices: use a TIMESTAMP or DATETIME column type rather than storing raw integers — databases can index and query date types efficiently. Always store in UTC — let the application layer handle timezone conversion for display. In PostgreSQL, use TIMESTAMPTZ (timestamp with time zone) which stores UTC internally. In MySQL, use DATETIME if you manage UTC yourself, or TIMESTAMP (stored as UTC, returned in session timezone). Avoid storing epoch seconds as integers in modern databases.
Unix timestamps are unaffected by Daylight Saving Time (DST) — they always count elapsed seconds since epoch in UTC, and UTC has no DST. DST only affects how you display a timestamp in a local timezone. When converting a local time to a timestamp, the same local "clock time" can map to two different timestamps during the fall-back hour (DST end), creating ambiguity. Always convert using explicit timezone data (like IANA timezone names with a library like Intl.DateTimeFormat or Luxon) rather than assuming a fixed UTC offset.
The Unix epoch (timestamp 0) is 1970-01-01 00:00:00 UTC — chosen when Unix was being developed at Bell Labs in the early 1970s. Negative timestamps represent times before 1970 and are supported by most systems. The lowest representable time in a 32-bit system is timestamp -2,147,483,648, which is 1901-12-13 20:45:52 UTC. Modern 64-bit systems can represent times from billions of years in the past to billions of years in the future.
To compare timestamps: convert both to Date objects and compare their .getTime() values (milliseconds), or compare Unix timestamps directly as numbers. new Date(ts1 * 1000) > new Date(ts2 * 1000). To find the difference: Math.abs(ts1 - ts2) gives the difference in seconds; divide by 60 for minutes, 3600 for hours, 86400 for days. For human-readable relative times ("3 minutes ago"), use Intl.RelativeTimeFormat (modern browsers) or a library like date-fns or Luxon.

About This Timestamp Converter

This free Unix timestamp converter converts between Unix epoch timestamps and human-readable dates across multiple timezones. The live clock shows the current Unix time updated every second. All conversion runs in your browser.

When to use this tool

  • Converting API timestamps to readable dates
  • Debugging date/time issues in log files
  • Calculating time differences between timestamps
  • Verifying database timestamp values

Related Developer Tools

Base Converter JSON Formatter Cron Explainer REST API Checker

Related Articles

In-depth guides and technical articles.

View all →
Developer Aug 2, 2026
Two Strings Can Both Be Valid ISO 8601 and Still Be Unparseable by Each Other's Parsers — And the Y2038 Problem Isn't Solved Yet
ISO 8601 permits basic format (no hyphens: 20240315T143000), week dates, and comma as decimal separator — all valid by the standard, all rejected by most "ISO 8601 parsers" that actually implement the stricter RFC 3339 profile. Here's the Y2038 problem's remaining affected systems (32-bit embedded firmware, MySQL TIMESTAMP type), why PostgreSQL's "TIMESTAMP WITH TIME ZONE" doesn't store the timezone, and the precision mismatch that causes events within the same millisecond to appear simultaneous in the UI but distinguishable in the database.
Developer Jun 29, 2026
ISO 8601, Unix Timestamps, and the "Local Time in Database" Bug — A Practical Format Selection Guide
ISO 8601 UTC and Unix timestamps represent the same moments but encode different assumptions — and the most pervasive timestamp bug is storing DATETIME without timezone information, which breaks when servers change timezones, when DST transitions create missing hours, or when users in different timezones submit local timestamps. Here's the practical guide: when to use each format, why ISO 8601 UTC sorts lexicographically, and the date-only vs datetime semantic distinction that causes birthday-display bugs.
Developer Jun 22, 2026
Unix Timestamps: Why 1970, What Happens Before It, and Why 2038 Still Matters for Some Systems
Unix timestamp 0 is January 1, 1970 — chosen somewhat arbitrarily by early Unix developers and now inherited by virtually every language, database, and API. Here's why negative timestamps (pre-1970) work in some systems and break in others, the Y2K38 problem's detailed mechanics (which embedded systems are still at risk), and why JavaScript's 13-digit millisecond timestamps cause a constant source of "date showing as 1970" bugs.
Developer Jun 16, 2026
Y2K, Y2K38, and Excel's 1900 Leap Year Bug: The Dates That Break Software
Y2K cost $300–600 billion to mitigate. The Unix 2038 problem will overflow signed 32-bit timestamps on 19 January 2038. Excel has counted 29 February 1900 as a real date since the 1980s. Here's the structural causes of each date bug and which ones are still ticking.
Developer Jun 9, 2026
ISO 8601 and Date Handling Mistakes: The Bugs That Surface Months Later
"06/07/2024" means different dates in the US and UK. ISO 8601 solves this unambiguously. Here's the standard, common date handling mistakes (adding months with timedelta, DST in date arithmetic), storing UTC in databases, and the MySQL 2038 timestamp problem.