Timestamp Converter

A Unix timestamp is the count of seconds since 00:00:00 UTC on January 1, 1970, the moment called the Unix epoch. The POSIX standard treats every day as exactly 86,400 seconds and ignores leap seconds, so the value is a plain running count. Databases, APIs, and log files store time this way because the number is timezone-free and sorts in chronological order. This tool also reads and shows millisecond timestamps, which use the same epoch.

It checks the absolute value: anything 10^11 or larger counts as milliseconds, anything smaller counts as seconds. As milliseconds, 10^11 lands on March 3, 1973; as seconds, it lands in the year 5138, so real-world values on either side never overlap. If a number sits near the boundary, pick the unit yourself in the dropdown to override the guess.

Yes. Enter a negative timestamp and you get a date before the epoch, and the date-to-timestamp direction returns negative numbers too. JavaScript holds time as a 64-bit floating-point count of milliseconds, so the 32-bit overflow behind the year-2038 bug never applies here. The supported window runs roughly 273,000 years on each side of 1970.

When you enter a value like 2026-01-15T10:30:00 with no zone marker, the tool appends a Z and reads it as UTC. Without that rule, the same text would shift by your computer's offset, a frequent cause of off-by-one-day bugs. To use a specific zone, add an explicit offset such as +02:00, or switch the timezone setting to local.

It matters only where you store time as a signed 32-bit integer of seconds, which overflows at 03:14:07 UTC on January 19, 2038 and wraps to a 1901 date. JavaScript, Python, and PostgreSQL all use 64-bit time and are safe. MySQL's TIMESTAMP column is the common trap: it is 32-bit and caps at that same 2038 instant, so move those fields to DATETIME or BIGINT and check any legacy C or embedded code that still relies on a 32-bit time_t.