Timestamp Converter

The one number every backend agrees on

Wall-clock time is fine for humans. It is a mess for computers. Timezones move. Countries change their offsets. DST comes and goes. What every server, database, and log format agrees on is the Unix timestamp: an integer count of seconds since 1970-01-01 at midnight UTC.

Store your timestamps as integers. Format for display only at the edge, in the user's timezone. That one habit prevents ninety per cent of the time-related bugs I have ever chased in production.

Gotchas worth knowing

• Seconds vs milliseconds. Most SQL databases, Python time.time(), and Go time.Unix() use seconds. Most JavaScript APIs use milliseconds. Mixing them by accident is the classic off-by-1000 bug.
• Naive datetimes. A Python datetime or a MySQL DATETIME without a timezone is ambiguous. Store TIMESTAMP (UTC) or explicitly attach a timezone.
• DST jumps. Every year, some wall-clock times either happen twice (fall back) or never happen (spring forward). Cron jobs scheduled at those local times misfire. Use UTC for scheduling.
• Leap seconds. Unix time ignores them. It is not a strict count of physical seconds. Fine for almost everything; matters for astronomy, GPS, and some physics.
• Half-hour zones exist. India (+05:30), Newfoundland (-03:30), and even 45-minute zones (Nepal +05:45). Never assume offsets are whole hours.

How this tool handles your data

• All parsing and formatting runs in your browser using Intl.DateTimeFormat. No timestamp is sent to a server.
• Nothing is stored beyond the current tab; nothing is logged.
• The site uses Google Analytics for page-view counts only. It does not observe the tool's input or output.

Frequently asked

What is Unix time?

Unix time is the number of seconds that have elapsed since 1970-01-01T00:00:00Z, ignoring leap seconds. It is the standard way to represent a moment in time in software — timezone-agnostic, sortable, and easy to store as an integer.

Seconds or milliseconds — which should I use?

Most databases and languages default to seconds. Most JavaScript APIs (Date, performance.now, etc.) use milliseconds. This tool auto-detects: anything with an absolute value above roughly 10^12 is treated as milliseconds, anything below as seconds. That threshold works because a second-based timestamp above 10^12 would be somewhere around the year 33670.

What timezone is Unix time in?

None. Unix time is a count of seconds since a fixed UTC instant. When you display it, you pick a timezone. The number itself does not change.

Why do I get a different date than my friend for the same timestamp?

Because you are viewing the same instant in different timezones. Set the same timezone at the top of the tool and you will see the same wall-clock time. A common gotcha: a log line timestamped '2024-07-23 00:00' has to say which zone it is in, or two people will interpret it differently.

What is ISO 8601?

A standard for writing dates and times. Looks like 2024-07-23T14:30:00Z or 2024-07-23T14:30:00-05:00. The T separates the date and time. The trailing Z means UTC; a signed offset like -05:00 means "this many hours off UTC". It sorts correctly as a string, which is why it is the format of choice for logs and APIs.

Does this tool handle DST correctly?

Yes. The conversions use Intl.DateTimeFormat, which knows the IANA timezone database — including every DST transition, both historical and current. Half-hour zones (India, Newfoundland) and 45-minute zones (Nepal, Chatham Islands) are all supported.

Is any timestamp I paste sent to a server?

No. Every conversion happens inside your browser tab. Nothing is sent, stored, or logged. Open DevTools → Network before you paste and you will not see a request go out.

Can I use this for scheduling cron jobs?

Yes, indirectly. The "build a timestamp from a date and time" panel is useful for computing "what Unix epoch is 2024-08-01 09:00 in Kingston?", which is the shape of question you have when scheduling a one-off job.