What is a Unix timestamp?

A Unix timestamp (also called Epoch time or POSIX time) is the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC, not counting leap seconds. It provides a single integer representation of a point in time that is unambiguous across time zones and locales. Unix timestamps are used pervasively in system programming, databases, APIs, and log files. Modern identifier formats like UUID v7 embed Unix timestamps directly to enable chronological sorting of distributed IDs.

Why does the Unix epoch start at January 1, 1970?

The choice of January 1, 1970 as the epoch origin is a historical convention from early Unix development at Bell Labs. The original Unix time was stored as a 32-bit signed integer counting seconds. Engineers needed a recent-enough date so the 32-bit range would cover a useful span of years, and 1970 was roughly contemporaneous with Unix's creation. The date itself has no astronomical or mathematical significance -- it was simply a practical round number close to the system's birth. Other systems use different epochs: Windows FILETIME counts from January 1, 1601, and the NTP epoch is January 1, 1900.

Should I use seconds or milliseconds for timestamps?

It depends on your precision requirements and ecosystem conventions. Traditional Unix timestamps use seconds (10 digits, e.g. 1700000000 ), which is sufficient for most server-side logging, file metadata, and database records. Millisecond timestamps (13 digits, e.g. 1700000000000 ) are standard in JavaScript ( Date.now() ), Java ( System.currentTimeMillis() ), and most frontend/API contexts where sub-second ordering matters. Use milliseconds when you need to differentiate events happening within the same second, such as high-frequency trading, distributed tracing, or UUID v7 generation where the embedded timestamp must be monotonic. Always document which unit your API returns to avoid the classic 1000x misinterpretation bug.

What is the Year 2038 problem (Y2038)?

The Year 2038 problem arises because many systems store Unix time as a signed 32-bit integer , which can represent values up to 2,147,483,647. That maximum corresponds to January 19, 2038 at 03:14:07 UTC . One second later the value overflows, wrapping around to a large negative number that maps to December 13, 1901. This affects embedded systems, legacy C libraries using time_t as a 32-bit type, file formats like ext3 inode timestamps, and network protocols with 32-bit time fields. Modern 64-bit systems use a 64-bit time_t , which extends the range to approximately 292 billion years in both directions, effectively eliminating the issue. If you maintain legacy systems, audit every time_t usage and migrate to 64-bit representations before 2038.

How do time zones affect Unix timestamps?

They don't -- and that is precisely the point. A Unix timestamp represents a single absolute instant in time measured from the UTC epoch. The value 1700000000 refers to the exact same moment regardless of whether you are in Tokyo (JST, UTC+9), London (GMT, UTC+0), or New York (EST, UTC-5). Time zone differences only come into play when you display or parse a human-readable date string. This is why timestamps are preferred over formatted date strings in APIs, databases, and log aggregation: they eliminate ambiguity caused by DST transitions, locale-specific formats, and missing UTC offset information. When you need to schedule recurring tasks with cron , be aware that cron expressions typically operate in local server time, not UTC, which can cause surprises around DST changes.

What is the difference between ISO 8601 and Unix timestamps?

ISO 8601 (e.g. 2024-11-14T22:13:20Z ) is a human-readable string format standardized for date/time interchange, while a Unix timestamp (e.g. 1731622400 ) is a compact integer representing the same instant. ISO 8601 is self-describing, includes explicit time zone offsets, and supports partial representations like dates without times. Unix timestamps are smaller, trivially comparable with integer arithmetic, and avoid parsing ambiguity. In practice, use ISO 8601 in user-facing APIs, JSON payloads, and configuration files where readability matters. Use Unix timestamps for internal storage, high-performance sorting, and compact binary protocols. Many systems accept both -- this converter lets you move freely between them.

Unix Timestamp Converter

Free online Unix timestamp converter between epoch time (seconds/milliseconds) and readable date formats

Current Time

Unix (seconds)

1770658930

Unix (milliseconds)

1770658930688

ISO 8601

2026-02-09T17:42:10.688Z

Local Time

Feb 9, 2026, 5:42:10 PM

Convert Timestamp

Input

Enter a timestamp or date to convert

Supported Formats

Unix seconds

1234567890

Unix milliseconds

1234567890000

ISO 8601

2024-01-01T12:00:00Z

Date string

Jan 1, 2024

Frequently Asked Questions

Cron

Build cron expressions

JSON

Validate, format & convert JSON

Diff

Compare text changes

UUID

Generate v4, v7, ULID

Unix Timestamp Converter

Current Time

Convert Timestamp

Supported Formats

Frequently Asked Questions

What is a Unix timestamp?

Why does the Unix epoch start at January 1, 1970?

Should I use seconds or milliseconds for timestamps?

What is the Year 2038 problem (Y2038)?

How do time zones affect Unix timestamps?

What is the difference between ISO 8601 and Unix timestamps?

You Might Also Like

Cron

JSON

Diff

UUID

Current Time

Convert Timestamp

Supported Formats

Frequently Asked Questions

What is a Unix timestamp?

Why does the Unix epoch start at January 1, 1970?

Should I use seconds or milliseconds for timestamps?

What is the Year 2038 problem (Y2038)?

How do time zones affect Unix timestamps?

What is the difference between ISO 8601 and Unix timestamps?