Unix Timestamp to Date

Unix Timestamp to Date is a free tool that converts a Unix timestamp into UTC and the corresponding date and time in your local timezone.

Why do some logs and APIs use Unix time?

Some logs and APIs use Unix time because it represents an instant as a numeric offset from January 1, 1970, at 00:00:00 UTC. The conventional unit is seconds, although some systems use milliseconds, microseconds, or nanoseconds.

A timestamp does not contain a formatted calendar date or a timezone name. That makes it practical for sorting events, comparing durations, and passing dates between systems without choosing a display format. Conversion becomes useful when debugging an API response, checking a scheduled job, reviewing an authentication token, or reading a third-party data export.

Unix time also avoids daylight saving transitions at the storage level. Timezone rules are applied when software turns the timestamp into a local date. POSIX-style Unix time does not represent leap seconds as distinct timestamp values, so it should not be treated as a continuous astronomical time scale.

A repeatable check for a single value

1. Copy only the numeric timestamp. Remove field names, commas, quotation marks, or other surrounding content.
2. Place it in the Unix timestamp field.
3. Read the UTC value first. UTC gives you a stable reference that does not depend on the computer's timezone.
4. Compare it with Your local timezone when you need to understand when the event occurred for someone in your current timezone.
5. Verify the unit and source if the year is implausible or the value differs sharply from the expected event time.

For a small reference case, input 0 corresponds to January 1, 1970, at 12:00:00 a.m. UTC. The local result may fall on December 31, 1969, in U.S. timezones west of UTC.

Another exact reference is input 946684800. Its UTC interpretation is January 1, 2000, at 12:00:00 a.m. A local conversion in much of the United States shows an evening time on December 31, 1999. The date difference is expected because the instant is being displayed in another timezone.

Why is the converted date off by hours or years?

A date that is off by hours usually reflects a timezone difference, while a date that is off by decades often indicates the wrong unit. Start with the UTC result, then check how the source system defines its value.

• Seconds and milliseconds were confused. JavaScript dates commonly use milliseconds, while conventional Unix timestamps use seconds. In JavaScript, a seconds value is commonly multiplied by 1,000 before passing it to Date.
• UTC was mistaken for local time. An event at midnight UTC occurs on the previous calendar day in several U.S. timezones.
• Daylight saving time changed the offset. A location such as New York does not keep one fixed UTC offset throughout the year.
• The value was altered by a spreadsheet. Scientific notation, rounding, or automatic formatting can change long numeric values.
• Extra characters were copied. Values such as timestamp=946684800 or "946684800" are not plain numeric timestamp input.
• The source uses another epoch. Some file formats and platforms count from a date other than January 1, 1970.

This tool's invalid-input behavior is not documented. If an empty, nonnumeric, fractional, or unusually large value does not produce a usable date, check the source format rather than assuming the value is Unix seconds.

Which timestamp inputs need extra care?

Inputs need extra care when they include anything beyond an ordinary integer count of seconds. Unix timestamp conventions are simple, but implementations differ in the ranges and numeric syntax they accept.

Spaces around a number may be trimmed by some parsers and rejected by others. Characters unsupported by the applicable numeric syntax have no meaning inside the numeric value, and support depends on the parser. A blank input provides no instant to convert. Decimal fractions can represent subsecond precision, but support and rounding behavior depend on the receiving implementation.

Negative timestamps conventionally identify instants before the Unix epoch. For example, -1 represents one second before January 1, 1970, at 00:00:00 UTC. Support for pre-epoch dates varies, and this tool's documented behavior does not state its accepted range.

Very long values can exceed a language, database, or date library's supported range. Preserve the original value while debugging so that a failed conversion does not lead to destructive edits or repeated rounding.

When can you skip timestamp conversion?

Skip conversion when no person needs to read the calendar date or when the source already supplies a clear ISO 8601 value. Machine-to-machine data can usually remain numeric, provided both systems agree on the unit and epoch.

Manual conversion of Unix timestamps is also a poor fit for thousands of records or a recurring production workflow. Use an automated route instead, such as a database date function, a spreadsheet formula, or a small script. JavaScript, Python, SQL databases, and command-line date utilities can convert batches, but their expected units and timezone defaults differ.

Do not replace the stored timestamp with a formatted local date solely for debugging. Keep the original value and add a derived display field. This preserves accurate sorting and allows the same instant to be shown in another timezone later. For the reverse operation, Date to Unix Timestamp is the more direct tool.

Questions developers ask about Unix time

Does a copied Unix timestamp retain its original timezone?

No. A Unix timestamp identifies an instant and does not retain the timezone used when it was created. If the original timezone matters for scheduling or legal records, store a timezone identifier such as America/Chicago separately.

Can a Unix timestamp contain a decimal point?

Yes, a fractional value can represent fractions of a second in systems that support it. Acceptance and precision vary, so check the producing API's schema before removing the decimal portion. Truncating and rounding can identify different instants near a second boundary.

Can I enter an ISO 8601 date in the timestamp field?

An ISO 8601 value such as 2026-09-18T14:30:00Z is a formatted date rather than a Unix timestamp. Convert it in the opposite direction with Date to Unix Timestamp, and confirm whether an offset or trailing Z is present.

Why do command-line conversions differ between Linux and macOS?

The GNU and BSD versions of the date command use different options for epoch conversion. A command copied from a Linux example may fail on macOS even when the timestamp is valid. Check the local manual page and set UTC explicitly when comparing output across machines.

Should an API send timestamps as JSON numbers or strings?

Either can work if the API contract defines the unit, precision, and accepted range. Numbers are convenient for arithmetic, while strings can prevent precision loss in consumers that cannot safely represent very large integers. Keep timestamp units and number-versus-string representation consistent within the same API.

Before acting on a converted value, confirm the source unit, compare the UTC result with the event you expected, and retain the original timestamp for reference.