← All tools

Stays in your browser

Unix Timestamp Converter Online

Free timestamp converter. Convert Unix seconds/millis to ISO and local time — entirely in your browser.

Now
1791947914 · 2026-10-14T03:18:34.638Z
ISO
2026-10-14T03:18:34.000Z
UTC
Wed, 14 Oct 2026 03:18:34 GMT
Local time
Wed Oct 14 2026 03:18:34 GMT+0000 (Coordinated Universal Time)
Unix
1791947914 / 1791947914000

Timestamps without timezone bugs

A Unix timestamp counts seconds since 1970-01-01 UTC, ignoring leap seconds. That definition is deliberately boring: it has no timezone, so the same instant is the same number on every machine, and converting to a human-readable time is a display decision made later.

The most common production bug is unit confusion. Ten digits means seconds, thirteen means milliseconds, and a system that guesses wrong is off by a factor of a thousand, which turns a date in 2026 into a date in 1970. Check the digit count before assuming, and be explicit in your API contract so the next developer does not have to guess either.

Store UTC everywhere and convert only when you render. If a service stores local times, then a daylight-saving transition, a server in another region, or a user in a third one will eventually produce an appointment that is an hour off. Keeping the stored form absolute and the rendered form local removes that whole class of bug.

FAQ

What is a Unix timestamp?
Seconds (or milliseconds) since 1970-01-01 UTC — common in logs and APIs.
Seconds vs milliseconds?
About 10 digits is seconds; 13 digits is usually millis. You can also switch modes.
How are time zones handled?
ISO/UTC show universal time; local uses your browser timezone.
How do I get the current Unix timestamp?
In a browser, Math.floor(Date.now() / 1000) gives seconds. On a server, every mainstream language has an equivalent, such as date +%s in a shell. Prefer the platform's UTC clock over anything derived from a locale setting, since locale settings are exactly what causes drift.
Why is my converted timestamp off by a few hours?
Almost always a timezone that was applied twice or not at all. A Unix timestamp has no timezone, so an offset in the result means the input was parsed as local time somewhere. Confirm the value is being read as UTC, then handle offsets only at the display step.
What is the Year 2038 problem?
Systems that store seconds in a signed 32-bit integer run out of range on 2038-01-19. Mitigation is to use 64-bit integers, and most current platforms already do. It is worth checking in embedded code, older database columns, and file formats, where 32-bit fields still linger.

Related tools