Unix Timestamp Converter — Epoch to Human Date

Name: Unix Timestamp Converter — Epoch to Human Date
Author: EverydayTools

Convert epoch seconds or milliseconds to dates and back for APIs, logs, JWT claims, and SQL—everything runs locally in your browser.

Browser-onlyNo uploadsNo signupWorks offline after first load100% local processingSafe for API + DB debugging

Current timestamp: —

Quick Presets

Timezone

Output is shown in selected timezone and UTC simultaneously.

Timestamp input

Non-ISO date strings may behave differently across browsers.

JWT Expiry Helper

Output size: 0 chars

Paste a timestamp or date to generate results. Example: 1704067200

Did you know?

Unix timestamps are timezone-independent, and JavaScript `Date.now()` returns milliseconds.

By Muhammad Abdullah Rauf · Founder, EverydayTools.proUpdated 2026-05-17

What is a Unix timestamp converter?

A Unix timestamp converter translates between Unix timestamps (seconds since January 1, 1970 UTC) and human-readable date/time strings — in both directions.

A Unix timestamp (also called epoch time or POSIX time) is an integer counting the seconds elapsed since the Unix epoch: January 1, 1970 at 00:00:00 UTC. It is the universal date representation in software systems because it is timezone-independent, unambiguous, and trivially comparable (larger = later). Most programming languages, databases, APIs, and log systems store timestamps in this format.

The converter handles two use cases: (1) you have a raw Unix timestamp from a log file, API response, or database field and need to know what date/time it represents; (2) you have a human-readable date and need the Unix timestamp to use in a query, API call, or code. The converter also handles millisecond timestamps (used in JavaScript's Date.now(), Kafka, and most modern APIs) in addition to second-precision Unix time.

Quick answers

Concise answers for common searches — definitions, steps, and comparisons.

Why does storing local time in a database create a DST ambiguity bug?

When clocks fall back (DST ends), the local hour from 1:00–1:59 AM occurs twice — once in daylight time and once in standard time. If an application stores '2026-11-01 01:30:00' as a local time string without a timezone, it is impossible to determine whether this is 1:30 AM EDT (UTC-4 = 05:30 UTC) or 1:30 AM EST (UTC-5 = 06:30 UTC) — a 1-hour ambiguity. Queries that filter by time range across DST transitions return wrong results, duplicate records appear, or event ordering is corrupted. The correct pattern: always store timestamps as UTC Unix integers or UTC ISO 8601 strings (ending in 'Z'). Convert to local time only at display time using the user's IANA timezone (e.g., America/New_York). This makes storage unambiguous and arithmetic correct.

How do you detect whether a timestamp is in seconds or milliseconds?

The digit count is the reliable detector: Unix second timestamps have 10 digits as of 2026 (the range 1,000,000,000–2,147,483,647 covers 2001–2038). Unix millisecond timestamps have 13 digits (1,000,000,000,000–2,147,483,647,000 covers the same range × 1000). In JavaScript: const isMs = timestamp > 1e12. In Python: is_ms = timestamp > 1_000_000_000_000. Sanity check: convert the timestamp with both interpretations and check which gives a plausible recent date. If seconds interpretation gives year 2025 but milliseconds gives year 57,000 — it's seconds. If seconds gives year 1970 but milliseconds gives year 2025 — it's milliseconds. Never rely on field names like 'created_at_ms' without verifying the actual digit count.

How do you perform timezone-safe date range queries using Unix timestamps?

Timezone-safe date range queries require converting the business-logic date boundaries to UTC Unix timestamps before querying. Example: query all events on 'May 2, 2026' in America/New_York (UTC-4 in May): start = Unix timestamp of 2026-05-02T00:00:00-04:00 = 1746158400. end = Unix timestamp of 2026-05-02T23:59:59-04:00 = 1746244799. Query: WHERE event_ts BETWEEN 1746158400 AND 1746244799. Never write WHERE DATE(event_ts) = '2026-05-02' using the database server's local timezone — this silently varies based on where the server is deployed. The pattern: compute boundary timestamps in application code using the user's timezone, pass integers to the database. This query is timezone-explicit, index-friendly (Unix integer comparison), and portable across database servers in any region.

How to use Unix Timestamp Converter — Epoch to Human Date

Get the timestamp
Copy a Unix timestamp from a log file, API response (usually a JSON field like 'created_at' or 'timestamp'), database query result, or your code.
Determine precision
Check the number of digits. 10-digit numbers are second-precision (e.g., 1746172800). 13-digit numbers are millisecond-precision (e.g., 1746172800000). Select the correct precision option.
Convert to human-readable
Paste the timestamp and click Convert. The result shows UTC time and your local timezone equivalent. You can also select any specific timezone.
Convert from date to timestamp
Switch to 'Date → Timestamp' mode. Enter a date and time, select the source timezone, and get the Unix timestamp. Useful for writing date-range queries or API request parameters.
Copy the result
Copy either the converted timestamp or the formatted date string for use in your code, query, or documentation.

Who uses Unix Timestamp Converter — Epoch to Human Date?

Common real-world scenarios where this tool saves time.

Backend developers

Debugging logs and traces

Log aggregation tools (Datadog, Splunk, CloudWatch) show raw timestamps in some views. Convert to local time to correlate errors with deployments, traffic spikes, or user actions.

Data engineers

Writing time-range queries

Databases like PostgreSQL, MySQL, and BigQuery accept Unix timestamps in WHERE clauses. Convert human dates to timestamps before writing partition filters or range queries.

API integrators

Parsing API responses

REST APIs frequently return timestamps as Unix integers (Stripe, Twilio, GitHub). Convert to confirm the date/time is what you expect before processing.

Workflow guides

Step-by-step chains that connect related tools for common tasks.

Log timestamp → human date → API query

Paste the Unix timestamp (10 digits = seconds, 13 = milliseconds).
Confirm UTC vs local display — Unix timestamps are always stored as UTC (POSIX time).
Paste the matching epoch into API filters or paste the API JSON into JSON Formatter to inspect created_at fields.
Extract raw integers from unstructured logs with Regex Tester (pattern \b\d{10}\b) before converting here.

Unix Timestamp Converter — Epoch to Human Date examples

Debug a log entry timestamp

Input

Log line: [1746172800] ERROR connection timeout

Output

1746172800 = 2026-05-02 00:00:00 UTC = 2026-05-01 20:00:00 EDT

The error occurred at midnight UTC, which was 8 PM Eastern the night before — this helps correlate with the deployment that happened at 7:45 PM EDT.

Build a date-range API query

Input

Need Unix timestamps for 2026-01-01 00:00:00 UTC to 2026-12-31 23:59:59 UTC

Output

Start: 1735689600 · End: 1767225599

Use these values in API parameters like ?start=1735689600&end=1767225599 or SQL WHERE clauses: WHERE created_at BETWEEN 1735689600 AND 1767225599.

How Unix timestamp arithmetic works

Unix time counts non-leap seconds since January 1, 1970 00:00:00 UTC (the Unix epoch), as defined by POSIX.1-2017. The browser's JavaScript Date object converts between Unix timestamps and UTC-based date components using the host system's IANA timezone database (TZDB). For second-precision: Math.floor(Date.now() / 1000). For millisecond-precision: Date.now(). Timezone display uses Intl.DateTimeFormat, which reads the IANA TZDB built into the OS — so results reflect the correct DST offset for the selected timezone at the given moment.

Formula

Timestamp (s) → date:  new Date(timestamp * 1000).toISOString()
Timestamp (ms) → date: new Date(timestamp).toISOString()
Date string → timestamp (s): Math.floor(new Date('2026-05-02T00:00:00Z').getTime() / 1000)
Current timestamp (s):  Math.floor(Date.now() / 1000)
Current timestamp (ms): Date.now()

Limitations

Integers above Number.MAX_SAFE_INTEGER (2^53 − 1 = 9,007,199,254,740,991) lose precision in JavaScript — affects timestamps beyond year 285,428,750
Dates before 1970-01-01 use negative timestamps — verify your database and language supports negative epoch values
DST transitions cause one clock hour to occur twice — always store UTC timestamps, never local time, to avoid ambiguity
JavaScript's Date object does not support sub-millisecond precision — use performance.now() or BigInt for high-resolution timing

Sources

Reference tables

Unix timestamp vs ISO 8601 vs RFC 2822 — choosing the right format

Different timestamp formats suit different contexts. Mixing them is the most common source of parsing bugs across systems.

Format	Example	Best for	Avoid when
Unix (seconds)	1746172800	Database storage, API parameters, arithmetic, sorting	User-facing display — show a formatted date instead
Unix (milliseconds)	1746172800000	JavaScript Date, Kafka events, modern REST APIs	Systems expecting second-precision — divide by 1000
ISO 8601 (UTC)	2026-05-02T00:00:00Z	Logs, exports, inter-system data exchange, JSON APIs	Pure arithmetic — parse to Unix first for math
ISO 8601 (offset)	2026-05-02T08:00:00+08:00	Human-readable logs with timezone context	Storage — the offset may change with DST; store UTC instead
RFC 2822	Sat, 02 May 2026 00:00:00 +0000	Email headers (From, Date fields), HTTP Date header	APIs and databases — verbose, non-numeric, harder to parse
Relative (human)	'2 days ago', 'just now'	User-facing timestamps in UI	Data storage — cannot be reliably reversed to an absolute time

Rule of thumb: store as Unix seconds (compact, arithmetic-friendly), display as ISO 8601 or locale-formatted string, and never store timezone-offset strings in databases.

Getting the current Unix timestamp — language quick reference

Code snippets for the most common languages and environments. All return seconds since 1970-01-01T00:00:00Z.

Language / Environment	Current Unix seconds	Current Unix milliseconds	Date from Unix seconds
JavaScript / Node.js	Math.floor(Date.now() / 1000)	Date.now()	new Date(ts * 1000)
Python 3	int(time.time())	int(time.time() * 1000)	datetime.fromtimestamp(ts, tz=timezone.utc)
PHP	time()	round(microtime(true) * 1000)	date('Y-m-d H:i:s', ts)
Go	time.Now().Unix()	time.Now().UnixMilli()	time.Unix(ts, 0).UTC()
Java / Kotlin	System.currentTimeMillis() / 1000L	System.currentTimeMillis()	new Date(ts * 1000L)
Ruby	Time.now.to_i	(Time.now.to_f * 1000).to_i	Time.at(ts).utc
PostgreSQL	EXTRACT(EPOCH FROM NOW())::int	EXTRACT(EPOCH FROM NOW()) * 1000	TO_TIMESTAMP(ts) AT TIME ZONE 'UTC'
MySQL	UNIX_TIMESTAMP()	UNIX_TIMESTAMP() * 1000	FROM_UNIXTIME(ts)
C# / .NET	DateTimeOffset.UtcNow.ToUnixTimeSeconds()	DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()	DateTimeOffset.FromUnixTimeSeconds(ts).UtcDateTime
Rust	SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()	...as_millis()	UNIX_EPOCH + Duration::from_secs(ts)

The 'ts' variable in all 'Date from Unix seconds' examples represents a Unix second-precision integer. For millisecond inputs, omit the * 1000 multiplication.

Best practices

Always store timestamps as UTC Unix seconds in databases

Unix seconds are timezone-neutral, arithmetically comparable, and use minimal storage. Storing local time with timezone offsets causes ambiguity during DST changes (one local hour occurs twice). Convert to human-readable format only at display time.

Check precision before converting: 10 digits = seconds, 13 digits = milliseconds

A 13-digit timestamp divided by 1000 gives the correct second value; a 10-digit timestamp multiplied by 1000 gives the correct millisecond value. Mixing them off by 1000× shows year ~57,000 (too large) or year ~1970 (too small) — both obvious in output but dangerous in production code.

Use ISO 8601 in logs and API responses; use Unix seconds for storage and arithmetic

ISO 8601 strings (2026-05-02T00:00:00Z) are human-readable in log viewers and universally parseable. Unix seconds are compact, sort lexicographically, and support direct subtraction for duration math. Use each format in its context.

Schedule cloud jobs in UTC, not server local time

AWS EventBridge, GCP Cloud Scheduler, and Kubernetes CronJobs default to UTC. Local time schedules silently shift by an hour during DST transitions — a 9 AM EST job becomes 8 AM or 10 AM after clock changes. Always specify UTC or an explicit IANA timezone.

Common mistakes to avoid

Confusing seconds and milliseconds

A 10-digit timestamp is seconds; 13 digits is milliseconds. If your timestamp is 1000× too large (showing year 57000), switch to milliseconds mode.

Ignoring timezone when converting to human date

Unix timestamps are absolute UTC. The human-readable output depends on which timezone you apply. A meeting at 1746172800 is 8:00 AM SGT but midnight UTC — always specify the timezone.

Using Unix timestamps in user-facing displays

Never display raw Unix timestamps to users. Convert to a locale-aware formatted date (e.g., 'May 2, 2026' or '2 days ago') using Intl.DateTimeFormat in JavaScript or equivalent.

Frequently Asked Questions

What is Unix epoch time?

Unix epoch (or Unix time) counts the number of seconds that have elapsed since January 1, 1970 at 00:00:00 Coordinated Universal Time (UTC). It is the standard time representation in Unix and POSIX operating systems, and is used by virtually all programming languages and database systems.

Why is 1970 the starting point?

January 1, 1970 was chosen as the epoch when Unix was developed in the early 1970s at Bell Labs — it was a recent, convenient reference point. The choice was somewhat arbitrary; it had no special mathematical significance.

What is the Year 2038 problem?

On January 19, 2038, 32-bit signed integers used to store Unix timestamps will overflow (2³¹ - 1 = 2,147,483,647 seconds = January 19, 2038 03:14:07 UTC). Modern 64-bit systems are not affected, but legacy embedded systems and older databases may fail. 64-bit Unix time won't overflow until the year 292,277,026,596.

What's the difference between Unix timestamp and ISO 8601?

Unix timestamp is an integer (1746172800). ISO 8601 is a human-readable string format (2026-05-02T00:00:00Z). Unix timestamps are better for storage, arithmetic, and API parameters. ISO 8601 is better for human-readable logs, exports, and inter-system data exchange.

Does JavaScript use seconds or milliseconds?

JavaScript uses milliseconds. Date.now() returns milliseconds since epoch. To convert to seconds (for most Unix APIs): Math.floor(Date.now() / 1000). To convert a Unix second timestamp to a JS Date: new Date(timestamp * 1000).

How do I get the current Unix timestamp in different languages?

JavaScript: Math.floor(Date.now() / 1000). Python: import time; int(time.time()). PHP: time(). Ruby: Time.now.to_i. Java: System.currentTimeMillis() / 1000L. Go: time.Now().Unix(). SQL (PostgreSQL): EXTRACT(EPOCH FROM NOW()). SQL (MySQL): UNIX_TIMESTAMP().

What is the maximum Unix timestamp value?

On 64-bit systems (all modern computers and servers), the maximum Unix timestamp is 9,223,372,036,854,775,807 seconds — corresponding to the year 292,277,026,596. In practice, this is unlimited for any foreseeable use. Only legacy 32-bit systems face the 2038 overflow limit (2,147,483,647 = January 19, 2038).

How do I convert a Unix timestamp to a readable date?

Paste the Unix timestamp into this tool and it converts immediately. To tell it apart: 10-digit numbers are second-precision (e.g. 1746172800), 13-digit numbers are millisecond-precision (e.g. 1746172800000). The tool detects precision automatically and shows both UTC and your local timezone. To convert manually in JavaScript: new Date(1746172800 * 1000).toISOString() for seconds, or new Date(1746172800000).toISOString() for milliseconds.

What is the difference between epoch time in seconds and milliseconds?

A second-precision Unix timestamp (10 digits, e.g. 1746172800) counts seconds elapsed since 1970-01-01T00:00:00Z. A millisecond-precision timestamp (13 digits, e.g. 1746172800000) counts milliseconds — it is exactly 1000× larger. JavaScript's Date.now() and most modern APIs return milliseconds. C, Go, Rust, Python's time.time(), and most Unix/Linux tools use seconds. Check the digit count before converting: if you convert a millisecond timestamp as if it were seconds, you get a date in year 57,000+.

Why does my converted timestamp show the wrong date or time?

Three common causes: (1) Precision mismatch — the most frequent error. A 13-digit millisecond timestamp treated as seconds shows a year around 57,000. Divide by 1000 first, or switch the tool's precision mode to milliseconds. (2) Timezone confusion — Unix timestamps are always UTC. If you see a date that is off by your timezone offset (e.g. 8 hours), you are converting correctly but the display timezone is different from what you expected. (3) Negative timestamp — a timestamp of -86400 is December 31, 1969, not an error.

How do I fix a timestamp timezone mismatch in my application?

Always store and transmit timestamps as UTC Unix integers (seconds or milliseconds). Never store a local time or timezone-offset string in a database. Convert to local time only at the display layer using Intl.DateTimeFormat with the user's IANA timezone: new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York' }).format(new Date(ts * 1000)). This way the stored value is unambiguous regardless of where the server or user is located.

What Unix timestamp corresponds to January 1, 2026 at midnight UTC?

1735689600 seconds (1,735,689,600). To compute any date's timestamp: Math.floor(new Date('2026-01-01T00:00:00Z').getTime() / 1000) in JavaScript, or int(datetime(2026,1,1,tzinfo=timezone.utc).timestamp()) in Python 3. Use the reverse direction in this tool — enter the date and select UTC to get the timestamp instantly.

Privacy, accuracy, and trust

Privacy

All timestamp conversion runs in your browser using JavaScript's built-in Date object and Intl.DateTimeFormat. No data is transmitted to any server.

Accuracy

Conversions follow the ECMAScript Date specification. The Unix epoch is January 1, 1970 00:00:00 UTC per POSIX.1-2017. Timezone offsets use the IANA timezone database built into your operating system.

The Year 2038 problem affects 32-bit systems only — all modern 64-bit computers and servers are unaffected. JavaScript uses 64-bit floats for Date, supporting timestamps to year 275,760.

Part of Developer Tools

More free tools for the same workflow.