Unix Timestamp Converter

Complete Guide to Unix Timestamps, Epoch Time, and UTC Conversion

Every database row, API response, log entry, and JWT claim that records "when" something happened likely stores time as a number — not as a human-readable date string. That number is almost always a Unix timestamp: the count of seconds (or milliseconds) since January 1, 1970, 00:00:00 UTC, a moment known as the Unix epoch. Developers encounter these integers constantly, yet converting between epoch values and calendar dates remains a recurring source of bugs, especially across time zones, daylight saving transitions, and mixed precision (seconds versus milliseconds).

ToolsFree.org provides a fast, privacy-focused Unix timestamp converter that runs entirely in your browser. Convert epoch seconds or milliseconds to readable UTC and local dates, or encode any datetime back to Unix time — without sending data to a server. This page gives you both the tool and the deep technical context to work with timestamps confidently in backend services, front-end applications, and data pipelines.

What Is a Unix Timestamp?

A Unix timestamp represents elapsed time since the epoch as a single integer. In the most common form, it counts seconds since 1970-01-01T00:00:00Z (the "Z" denotes UTC, also called Zulu time). For example, 1704067200 corresponds to January 1, 2024, 00:00:00 UTC. Many JavaScript APIs and mobile SDKs instead use milliseconds — the same moment would be 1704067200000 — because JS Date.now() returns milliseconds for finer precision in browser environments.

Unix timestamps are timezone-agnostic at storage time. The integer always refers to an absolute instant on the global timeline. Display layers apply timezone offsets when rendering for users. Storing UTC-based epoch values avoids ambiguity; converting to "local time" is a presentation concern handled by libraries like PHP's DateTime, Python's datetime, JavaScript's Intl.DateTimeFormat, or Java's Instant and ZonedDateTime.

Seconds vs. Milliseconds: Avoiding the Most Common Bug

The single most frequent timestamp bug is a 1000× error: treating milliseconds as seconds or vice versa. If you pass 1704067200000 (milliseconds) to a function expecting seconds, the computed date lands tens of thousands of years in the future. If you pass seconds where milliseconds are expected, the date appears near the epoch in 1970.

Quick heuristics help during debugging. Current Unix seconds in the 2020s are 10-digit numbers (around 1.7 billion). Millisecond timestamps are 13-digit numbers (around 1.7 trillion). If your API returns a 13-digit value, divide by 1000 before feeding systems that expect seconds — or configure your ORM and JSON serializers explicitly. Document which precision your API uses in OpenAPI specs and README files so integrators do not guess.

How to Use This Timestamp Converter Step by Step

To decode a timestamp, paste the numeric value into the input field and select whether it represents seconds or milliseconds. The tool displays the equivalent UTC datetime and your browser's local timezone interpretation. To encode a date, pick a calendar date and time (or type an ISO 8601 string if supported), and the tool outputs the corresponding Unix value in both precisions.

Use the current-time button to snapshot "now" as a reference when correlating log lines. Copy results into tickets, SQL queries, or test fixtures. Clear between conversions when working with multiple incidents so you do not mix values from different debugging sessions.

UTC, Time Zones, and Daylight Saving Time

Coordinated Universal Time (UTC) is the global reference clock. It does not observe daylight saving time. "GMT" is often used interchangeably in casual conversation, though GMT as a legal time standard has nuances historians care about; in software, UTC is the correct term.

Local time zones apply offsets from UTC: US Eastern Standard Time is UTC−5; Central European Summer Time is UTC+2. Daylight saving shifts those offsets seasonally. A meeting at "2024-03-10 02:30" in US Eastern may not exist on the spring-forward day when clocks jump from 2:00 to 3:00. Timestamp conversion libraries must use timezone databases (IANA tzdata) — not fixed offsets — to handle DST correctly. When debugging user-reported "wrong time" bugs, always ask: what timezone was the user in, and did the stored value include an offset or assume UTC?

Unix Timestamps in Databases and ORMs

Relational databases offer multiple strategies. MySQL provides DATETIME, TIMESTAMP, and integer columns. PostgreSQL excels with TIMESTAMPTZ (timestamp with time zone), which stores UTC internally. MongoDB's Date type is BSON datetime in milliseconds. Redis often stores TTLs as seconds relative to now.

Laravel Eloquent casts created_at and updated_at to Carbon instances. Django uses timezone-aware datetimes when USE_TZ = True. Rails ActiveRecord converts to UTC in the database. Regardless of framework, migrations should document whether legacy tables store epoch integers or native datetime types — mixed schemas are common in long-lived products and cause integration pain during analytics exports.

Timestamps in APIs and JSON

JSON has no native datetime type. APIs typically return either ISO 8601 strings ("2024-01-15T14:30:00Z") or numeric epochs. ISO strings are human-readable in network traces; epochs are compact and sort lexicographically when formatted as fixed-width integers in logs. Stripe, GitHub, and many webhook providers use Unix seconds in event payloads. JavaScript ecosystems often prefer milliseconds in Date constructors.

When designing APIs, pick one format and document it. If you accept both, validate carefully — a client sending milliseconds where you expect seconds corrupts data silently. Include examples in OpenAPI schemas. For GraphQL, use custom scalars (DateTime) backed by consistent serialization rules.

Timestamps in Logs, Monitoring, and Debugging

Server logs frequently interleave ISO timestamps with epoch values from different subsystems. When correlating a user report ("error at 3:15 PM") with log lines stored in UTC epoch seconds, conversion tools bridge the gap. Distributed tracing systems like Jaeger and Zipkin use high-resolution timestamps — sometimes nanoseconds — for span ordering; know your tool's precision before comparing to second-granularity database records.

Monitoring alerts often threshold on epoch values: certificate expiry, token exp claims, scheduled job run_at columns. Paste suspicious values into a converter to verify whether a job failed because of a timezone misconfiguration or an actual scheduling error.

JWT, OAuth, and Token Expiry Claims

JSON Web Tokens carry iat (issued at) and exp (expiration) claims as NumericDate values — Unix seconds since epoch, per RFC 7519. When a token appears valid but API calls return 401, decode the payload (Base64URL — use our JWT decoder tool) and convert exp to human time. Clock skew between servers can cause edge-case failures if leeway is not configured; compare token times against NTP-synchronized server clocks.

OAuth authorization servers return expires_in as a duration in seconds from issuance, not an absolute timestamp. Add it to iat to compute wall-clock expiry. Refresh token rotations depend on accurate time math — document token lifetimes in runbooks and test near-boundary conditions.

Historical Limits and the Year 2038 Problem

32-bit signed integers max out at 2,147,483,647 — which corresponds to 2038-01-19 03:14:07 UTC when interpreted as Unix seconds. Legacy systems still using 32-bit time_t face the Year 2038 problem. Modern 64-bit platforms extended the range practically indefinitely for application purposes. When maintaining embedded or legacy C code, audit integer widths. Millisecond timestamps in JavaScript numbers are safe until far-future precision limits of IEEE 754 doubles — a separate concern from 32-bit seconds overflow.

ISO 8601 and Alternative Formats

ISO 8601 (2024-07-06T15:30:00+05:00) embeds timezone offsets explicitly and is preferred for human-facing APIs and configuration files. RFC 3339 is a profile of ISO 8601 common in internet protocols. When converting between ISO strings and epochs, parsers must respect offsets — a datetime with +05:00 is five hours earlier in UTC than the same local clock reading in New York. Never assume a string without offset is UTC unless your API contract says so.

Privacy and Security

Timestamp values alone rarely identify individuals, but combined with user IDs in support tickets they can reconstruct activity timelines. ToolsFree.org converts timestamps locally in your browser without uploading values. For production debugging, redact user identifiers when sharing converted times in public forums.