Skip to main content
Date & Time

Date & Time Tools

Convert Unix timestamps and epoch values into readable dates in any time zone, and turn calendar dates back into epoch seconds or milliseconds.

1 tool

Nearly every date-handling bug comes from confusing an instant with its representation. A Unix timestamp is an instant: a count of seconds since 1970-01-01T00:00:00Z, with no timezone and no calendar attached. What a screen shows — 14:30 on 18 September — is that instant rendered in a particular timezone, and the same instant legitimately renders as a different calendar date either side of midnight.

Sponsored

This space is reserved for a sponsor.

About Date & Time Tools

That distinction explains the most common complaint about timestamps, being off by one day. It is almost never an arithmetic error; it is an offset applied at the wrong end, or a date parsed as local time and then displayed as UTC. It also explains daylight saving bugs, because an offset is not a constant: a zone can change its offset twice a year, and some have changed their rules retroactively for past dates.

Conversion runs locally and needs no network, so it works offline — which also means your timestamps are not logged anywhere.

Frequently asked questions

Is my timestamp in seconds or milliseconds?

Check the magnitude. A ten-digit value is seconds: 1758200000 is September 2025 and fits in a signed 32-bit integer until 2038. A thirteen-digit value is milliseconds, which is what JavaScript's Date.now() returns. Sixteen digits is microseconds, used by some databases and log formats. If a converted date lands in 1970 or in the year 50000, the unit is wrong rather than the value.

Why is my converted date off by one day?

Because the instant was rendered in a different timezone from the one you had in mind. A timestamp for midnight UTC is 19:00 or 20:00 on the previous day in US time zones, so a date-only comparison differs legitimately. Confirm the unit first, then check whether the tool is displaying UTC or your local zone. A date entered without a time is ambiguous until the zone is stated, which is why storing a local date as a string causes this class of bug.

Does it handle daylight saving and historical timezones?

Conversion resolves named zones such as America/New_York against the IANA timezone database, so the correct offset is used for that specific instant, including daylight saving transitions. That is more robust than storing a fixed offset, because offsets change: zones have altered their rules, some have abolished daylight saving, and past dates resolve using the rules that were in force at the time. Prefer a named zone over a numeric offset whenever a date will be stored or compared.

What exactly is the Unix epoch?

1970-01-01T00:00:00 UTC. It was chosen as a convenient round number near the start of the computing era rather than for any astronomical reason. The epoch is defined in UTC and Unix time does not count leap seconds, so the value is a simple integer difference rather than a strict measure of elapsed physical time — which is exactly why it can be converted back and forth without drift.

What is the 2038 problem?

Systems that store Unix time in a signed 32-bit integer run out of range at 03:14:07 UTC on 19 January 2038, at which point the value overflows and dates wrap to 1901. It affects older C libraries, some embedded systems and databases with 32-bit timestamp columns. Moving to 64-bit, which current platforms generally already do, pushes the limit roughly 292 billion years out. For any long-lived timestamp — a certificate expiry, a licence, a maintenance contract — store the 64-bit form.

Related categories

Sponsored

This space is reserved for a sponsor.