What is the difference between a Unix timestamp and ISO 8601?

A Unix timestamp is a count of seconds since 1970-01-01T00:00:00Z, leap seconds excluded. ISO 8601 is a text string showing the date and time in a human-readable format, like `2026-01-15T14:30:00Z`. Same instant, different forms.

Why does the Unix timestamp not match the actual number of seconds since 1970?

Unix time excludes leap seconds. Every leap second added since 1972 causes the Unix clock to pause for one tick. Twenty-seven have been added as of 2026. The count you see is slightly less than the true elapsed seconds.

Can I use a Unix timestamp for events before 1970?

Yes, with negative numbers. A timestamp of `-86400` corresponds to 31 December 1969. Most systems handle negative Unix timestamps correctly. Some older databases and spreadsheet applications do not.

What does the `Z` at the end of an ISO 8601 timestamp mean?

It stands for "Zulu time," the military designation for UTC. The time is given in Coordinated Universal Time with no offset. A timestamp ending in `Z` equals one ending in `+00:00`.

How do I convert a Unix timestamp to my local time?

Take the Unix timestamp, add or subtract your UTC offset in seconds, then convert to a date-time. On 15 January 2026, New York sits at UTC-5. Subtract 5 hours' worth of seconds from the timestamp. The UTC Converter does this automatically for any zone.

Why store timestamps in UTC instead of local time?

Local time shifts. A timestamp stored as "2026-03-08 02:30:00" in a US Eastern zone is ambiguous: which 2:30 AM does it mean, the one before the spring-forward or the one after? UTC never observes daylight saving time and never moves. Store in UTC, convert for display.

UTC Timestamp Converter

Live Unix timestamp and ISO 8601 display

A server log entry, an API call, a database commit: they all need one shared moment pinned down. The live display above gives you that moment in two formats at once. Copy the whole number for your code. Copy the string for your logs. No mental arithmetic, no offset lookups.

The same instant wears different clothes depending on the format. A count like 1737338086 and the string 2026-01-15T14:30:00Z mark the identical point in time. The tool switches between them so you do not have to.

Unix epoch time

Unix time counts the seconds that have passed since 1 January 1970 at 00:00:00 UTC. It is a whole number. No decimals, no time zone offset, no daylight saving confusion.

Leap seconds are the catch. Unix time deliberately ignores them. When a leap second is inserted, the Unix clock freezes for that tick. The last insertion was 31 December 2016. Twenty-seven leap seconds have been added since 1972. The count you see is therefore slightly behind the true elapsed seconds since 1970, but that is the specification. Linux, macOS, Python's time.time(), JavaScript's Date.now() all follow this rule.

For code that stores timestamps, Unix time is the safest choice. It is time-zone-agnostic and sorts cleanly. The value on the display is what you would get from date +%s on a Linux server or int(time.time()) in Python.

Do not treat a Unix timestamp as local time. 1737338086 is always UTC. Feed it into a spreadsheet formatted for your local zone and the displayed time will be wrong unless you convert it first.

ISO 8601 format

ISO 8601 is the unambiguous, human-readable date-time format. The pattern: YYYY-MM-DDTHH:MM:SSZ. On the display you see it as 2026-01-15T14:30:00Z.

Breaking it down:

2026-01-15: date, year-month-day, largest unit first.
T: literal separator between date and time.
14:30:00: time in 24-hour clock, hours, minutes, seconds.
Z: time zone designator for UTC. It stands for "Zulu time," the military and aviation name for UTC.

The Z carries weight. Without a time zone indicator, a timestamp is ambiguous. 2026-01-15T14:30:00 could mean local time in Paris, New York, or Tokyo. 2026-01-15T14:30:00Z means exactly one thing: 14:30 UTC. When sending timestamps between systems, always include the Z or an offset like +01:00.

How to read an ISO 8601 timestamp

Read it left to right. Year, month, day. Then hours, minutes, seconds. The Z at the end tells you the offset is zero.

The silent failure: many programming libraries and databases default to local time when parsing a string that lacks a zone indicator. Store 2026-01-15T14:30:00 without the Z, and a server set to UTC-5 may interpret that as 14:30 local, which is 19:30 UTC. Your data shifts by five hours with no warning. Always append the Z.

RFC 3339

RFC 3339 is a profile of ISO 8601 built for internet protocols. HTTP headers, email timestamps, and most REST APIs use it. For UTC timestamps, RFC 3339 and ISO 8601 produce identical output: 2026-01-15T14:30:00Z. The difference surfaces with non-zero offsets. RFC 3339 requires +05:30 rather than the looser ISO 8601 variations.

When building an API, choose RFC 3339. It is the safest subset that every modern language can parse.

Common timestamp use cases

Use case	Best format	Why
Database storage	Unix timestamp	Fast sorting, no time zone issues
API responses	RFC 3339 / ISO 8601 string	Human-readable, standard for JSON
Log files	ISO 8601 with time zone	Debugging requires readable times
Database display columns	ISO 8601 in UTC	Avoids DST ambiguity across users
Cron jobs or scheduled tasks	Unix timestamp	Easy to compare and calculate intervals

Converting between timestamp formats

Type a Unix timestamp into the input field and the display shows the corresponding UTC date-time. Enter a date-time string in ISO 8601 format and it shows the Unix count.

The conversion is always to and from UTC. It cannot guess your local time zone. If you need Eastern Standard Time or India Standard Time, the UTC Converter handles offsets and daylight saving transitions.

Developer shortcut: copy the current Unix timestamp from the display and store it as a reference point. Test your code by converting it back to a date-time string and confirming it matches the UTC clock shown here.