Timestamp to Date
Date to Timestamp
Batch Timestamp Check
What a Unix Timestamp Represents
A Unix timestamp represents one exact instant measured from January 1, 1970 at 00:00:00 UTC. That starting point is often called the Unix epoch. A timestamp is not stored in New York time, London time, Tokyo time, or your browser's local time. It is an absolute count. Time zones only change how that instant is displayed to a person.
This is why the same timestamp can appear as different local dates around the world. A timestamp that is Monday evening in Los Angeles may already be Tuesday morning in Tokyo. The timestamp itself has not changed. Only the local calendar representation changed. If you are comparing API records, database rows, log lines, webhook payloads, or analytics exports, convert them to one reference before drawing conclusions.
For a general conversion between city-based time zones, use the time zone converter. This page is aimed at epoch values used by software systems, spreadsheets, databases, and logs.
Seconds vs Milliseconds
The most common timestamp mistake is using the wrong unit. Current Unix time in seconds is a 10-digit number. Current Unix time in milliseconds is a 13-digit number. JavaScript Date values use milliseconds. Many APIs, databases, command line tools, and programming languages use seconds. Some systems label the field clearly, while others leave you to infer the unit from the length of the number.
If a converted date lands in 1970 or far in the future, the unit is probably wrong. For example, treating milliseconds as seconds makes the date thousands of years ahead. Treating seconds as milliseconds pushes a modern timestamp back to January 1970. This converter lets you choose the unit explicitly so you can check both interpretations.
When documenting an API or spreadsheet, name the unit in the column or field: created_at_seconds, created_at_ms, unix_seconds, or timestamp_milliseconds. A short label prevents expensive mistakes later.
UTC, ISO 8601, and Local Display
The ISO 8601 UTC result ends with Z, which means zero offset from UTC. It is a portable format because it names both the date-time structure and the time reference. If you copy a timestamp into a ticket, bug report, database migration note, or incident timeline, the ISO UTC value is usually the safest readable form.
The UTC display is useful for systems that speak in UTC but not necessarily ISO syntax. The browser local display is useful when you want to understand what the same instant means on your own computer. If you need a specific city rather than browser local time, convert the ISO or timestamp through the time zone converter.
A timestamp should not be adjusted manually for a time zone before storing it. Store the instant, then format it for the viewer. Manual offset math is one of the main causes of duplicate, missing, or shifted records around daylight saving transitions.
Common Developer Uses
Unix timestamps show up in API responses, authentication tokens, cache headers, payment events, webhook signatures, queue messages, audit logs, analytics exports, cron jobs, and database records. They are popular because they sort naturally, compare quickly, and avoid language-specific date formatting problems.
Expiration fields such as exp, expires_at, valid_until, and not_before often use Unix time. When debugging an expired token or delayed webhook, convert the timestamp to UTC and local time before assuming the system is wrong. Many bugs are just time zone display mismatches.
When you need to measure the elapsed span between two converted timestamps, use the time duration calculator. When you need a live display of time remaining until a Unix-derived deadline, convert the timestamp to a date and then use the countdown calculator.
Logs, Incidents, and Audits
Incident timelines often combine data from several systems. One system may export Unix seconds, another may export ISO strings, another may show account-local time, and a human may write notes in their own time zone. Before ordering events, normalize everything to UTC. After the timeline is correct, you can add local display times for readability.
Be careful with spreadsheet imports. Large millisecond timestamps can be rounded or displayed in scientific notation if the column is treated as a normal number. For audit-quality work, keep the original timestamp text and the converted UTC value side by side.
If a record falls exactly at midnight, check the time zone before treating it as a date-only event. A UTC midnight timestamp can be the previous evening in North America and the morning in Asia-Pacific.
Data Quality Checks for Timestamps
When a timestamp looks wrong, check the unit first. A 10-digit value is usually seconds. A 13-digit value is usually milliseconds. A value that converts to January 1970 often means seconds were treated as milliseconds. A value that converts thousands of years into the future often means milliseconds were treated as seconds.
Next, check whether the system stores UTC, local wall time, or both. A Unix timestamp represents an instant, but a separate date string may have been generated in a local zone. If the two disagree, do not average them or adjust manually. Identify the source of truth and convert from that value consistently.
For migrations and imports, preserve the raw timestamp field. Converting everything to formatted text too early can remove precision, hide the original unit, or make sorting unreliable. Keep the raw seconds or milliseconds, the ISO UTC conversion, and any local display value in separate fields when accuracy matters.
Common Timestamp Field Names
Timestamp fields often appear with names such as created_at, updated_at, expires_at, exp, iat, nbf, valid_until, published_at, processed_at, paid_at, and deleted_at. The name tells you what event the timestamp describes, but it does not always tell you the unit. Check the documentation, inspect the number of digits, and compare a known recent value before building logic around the field.
Authentication tokens are especially sensitive to timestamp interpretation. JWT fields such as exp, iat, and nbf are defined as NumericDate values, usually seconds since the Unix epoch. JavaScript Date methods, however, expect milliseconds. Multiplying or failing to multiply by 1000 is a common cause of tokens appearing expired too early or valid too long.
When in doubt, convert the timestamp to ISO UTC and compare it with the event you expected. If the converted date is close but the local display looks off by several hours, that is probably a time zone display issue. If the converted date is decades off, that is usually a unit issue.