Unix Timestamp Converter

Convert epoch seconds or milliseconds to human-readable dates and back—for API debugging, logs, JWT exp, and SQL. UTC, local, and timezone output runs in your browser.

Loading tool…

By Muhammad Abdullah Rauf · Founder, EverydayTools.proUpdated 2026-06-02· Reviewed by EverydayTools Editorial Team

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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?

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

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

Unix Timestamp Converter 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.

FormatExampleBest forAvoid when
Unix (seconds)1746172800Database storage, API parameters, arithmetic, sortingUser-facing display — show a formatted date instead
Unix (milliseconds)1746172800000JavaScript Date, Kafka events, modern REST APIsSystems expecting second-precision — divide by 1000
ISO 8601 (UTC)2026-05-02T00:00:00ZLogs, exports, inter-system data exchange, JSON APIsPure arithmetic — parse to Unix first for math
ISO 8601 (offset)2026-05-02T08:00:00+08:00Human-readable logs with timezone contextStorage — the offset may change with DST; store UTC instead
RFC 2822Sat, 02 May 2026 00:00:00 +0000Email headers (From, Date fields), HTTP Date headerAPIs and databases — verbose, non-numeric, harder to parse
Relative (human)'2 days ago', 'just now'User-facing timestamps in UIData 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 / EnvironmentCurrent Unix secondsCurrent Unix millisecondsDate from Unix seconds
JavaScript / Node.jsMath.floor(Date.now() / 1000)Date.now()new Date(ts * 1000)
Python 3int(time.time())int(time.time() * 1000)datetime.fromtimestamp(ts, tz=timezone.utc)
PHPtime()round(microtime(true) * 1000)date('Y-m-d H:i:s', ts)
Gotime.Now().Unix()time.Now().UnixMilli()time.Unix(ts, 0).UTC()
Java / KotlinSystem.currentTimeMillis() / 1000LSystem.currentTimeMillis()new Date(ts * 1000L)
RubyTime.now.to_i(Time.now.to_f * 1000).to_iTime.at(ts).utc
PostgreSQLEXTRACT(EPOCH FROM NOW())::intEXTRACT(EPOCH FROM NOW()) * 1000TO_TIMESTAMP(ts) AT TIME ZONE 'UTC'
MySQLUNIX_TIMESTAMP()UNIX_TIMESTAMP() * 1000FROM_UNIXTIME(ts)
C# / .NETDateTimeOffset.UtcNow.ToUnixTimeSeconds()DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()DateTimeOffset.FromUnixTimeSeconds(ts).UtcDateTime
RustSystemTime::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.

When to use Unix Timestamp Converter vs related tools

Use the Timestamp Converter when you have a Unix integer or need one from a calendar date. Use the time zone converter for IANA offset math across regions; use the JWT decoder when the value is inside a signed token string.

Related toolUse this tool whenUse related tool when
Time Zone ConverterYou have a Unix timestamp and need readable UTC/local time, or date → Unix for API filters.You know the instant but need what clock time it is in Tokyo vs New York without manual offset math.
JWT DecoderYou only have the numeric exp or iat claim and want a quick expiry countdown.You have a full JWT string and need header, payload, and signature inspection—not just exp.
Cron ParserYou need the next run time as a Unix timestamp from a one-off date.You have a cron expression and need the schedule of upcoming runs in local time.
JSON FormatterYou already know which JSON field holds created_at or exp as an integer.You are debugging a minified API response and need to find timestamp fields first.

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.

Advertisement

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.

What is Unix time 0 and what date is it?

Unix time 0 is the epoch itself: January 1, 1970 at 00:00:00 UTC, also written as 1970-01-01T00:00:00Z in ISO 8601. All positive Unix timestamps count seconds after this moment; negative timestamps represent dates before 1970. Unix time 0 was an arbitrary choice made when POSIX/Unix was designed — it was a recent, convenient round date with no special mathematical significance.

What is the largest Unix timestamp before the Year 2038 overflow?

On 32-bit systems, the maximum signed 32-bit integer is 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. At 2,147,483,648 seconds, 32-bit systems overflow to a negative number and typically reset to December 13, 1901. Modern 64-bit systems are not affected: the 64-bit signed maximum (9,223,372,036,854,775,807 seconds) would not overflow until the year 292,277,026,596.

How do I get the current Unix timestamp in JavaScript?

Math.floor(Date.now() / 1000) gives the current Unix timestamp in seconds. Date.now() returns milliseconds; dividing by 1000 converts to seconds; Math.floor removes the decimal. For millisecond precision: Date.now(). For a string in ISO 8601: new Date().toISOString(). For POSIX shell: date +%s. For Python: import time; int(time.time()).

How do I convert a Unix timestamp to ISO 8601 format?

In JavaScript: new Date(timestamp * 1000).toISOString() produces 2026-05-02T00:00:00.000Z for a second-precision timestamp, or new Date(tsMs).toISOString() for milliseconds. In Python: datetime.utcfromtimestamp(ts).isoformat() + 'Z'. The ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) is the most portable for inter-system data exchange and is readable by JSON parsers, databases, and humans equally.

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

Related Tools

More free tools for the same workflow.

Time Zone Converter — Convert Time Between Cities

Convert time between cities and IANA time zones with DST handled automatically. No upload—runs locally in your browser. Free, no signup.

Date Calculator — Add, Subtract & Days Between Dates

Add or subtract days, weeks, months, or years from any date. Days-between mode included. No upload—runs locally in your browser. Free, no signup.

Advertisement

Reviewed by EverydayTools Editorial Team on 2026-05-20.