epoch-converter

Convert a Unix timestamp (in seconds or milliseconds) to a human-readable date-time — or pick a date and get the timestamp back. Auto-detects the unit, shows both UTC and your local timezone.

client-side only seconds & milliseconds local timezone auto-detected

live clock

seconds

milliseconds

UTC

epoch-timestamp.txt

Unix Timestamp

ISO 8601

Result UTC Time

Result Local Time

human-date-to-epoch

Date & Time (Local)

Epoch in Seconds

Epoch in Milliseconds

// seconds vs. milliseconds — the most common confusion

│

Unix timestamps traditionally count seconds since the epoch (January 1, 1970 UTC). A seconds-based timestamp is 10 digits long today (e.g. 1713876000). JavaScript's Date.now() returns milliseconds, making it 13 digits long (e.g. 1713876000000). This distinction causes one of the most reliable classes of off-by-1000x bugs: displaying a date 47 years in the past because seconds were used where milliseconds were expected, or displaying a date in the year 56,000 because milliseconds were stored as seconds.

In .NET: use DateTimeOffset.UtcNow.ToUnixTimeSeconds() for seconds and ToUnixTimeMilliseconds() for milliseconds. Do not use (long)(DateTime.UtcNow - new DateTime(1970,1,1)).TotalSeconds — that's fragile and loses the explicit "this is UTC" signal.
In JWT claims: exp, nbf, and iat are always in seconds, not milliseconds — a common off-by-1000 bug when a token is validated against DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() instead of ToUnixTimeSeconds().
In databases: SQL Server's DATEDIFF(SECOND, '1970-01-01', GETUTCDATE()) returns seconds. If you're storing a timestamp as a bigint, agree on the unit with the application layer before writing the first row — changing it later means migrating all existing values.

// what the Unix epoch actually is

│

The epoch is a fixed reference point: midnight UTC, January 1, 1970. Every Unix timestamp is just the number of seconds (or milliseconds) that have elapsed since that moment. There's nothing special about the date itself — it was chosen as a convenient origin point when Unix was being designed. One practical consequence: timestamps before 1970 are negative numbers, and some older APIs or parsers reject negative timestamps without explanation.

// the year 2038 problem

│

32-bit signed integers can hold Unix timestamps up to 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. Systems that store timestamps in a 32-bit int will overflow on that date. Most modern systems use 64-bit integers for timestamps, but the problem still surfaces in embedded systems, legacy databases using int columns for timestamps, or old serialization formats that pack timestamps into 4 bytes. If you're designing a new system, always use a 64-bit type for timestamps.