What is the Unix epoch?

It is midnight UTC on 1970-01-01, the reference point from which POSIX time counts seconds (ignoring leap seconds in the usual `time_t` sense). Positive values are after that instant; negative values represent times before 1970 in UTC-based libraries.

Should I store UTC or local time in databases?

Store UTC instants (or a TIMESTAMP WITH TIME ZONE that normalizes to UTC) and convert to local zones at display. Storing local civil time without offset causes ambiguous clocks during DST jumps and cross-region bugs. APIs should emit ISO 8601 with explicit offsets or `Z` for UTC.

What is ISO 8601 and why do APIs use it?

ISO 8601 strings like `2026-03-28T15:30:00Z` or `2026-03-28T10:30:00-05:00` encode calendar date, time of day, and UTC offset unambiguously. They sort lexicographically when using the same precision and offset convention—handy for logs and JSON fields.

Are Unix timestamps in seconds or milliseconds?

Unix `time_t` traditionally counts whole seconds; JavaScript `Date.now()` and many JSON APIs use milliseconds since epoch. Mixing them off by 1000× is a common bug—your tool should label units clearly. Some systems use microseconds in protobuf or logs—always read the spec.

What is the Year 2038 problem?

Signed 32-bit seconds-since-epoch overflows after `03:14:07 UTC on 19 January 2038`. Systems still using `int32` for timestamps need migration to 64-bit or string instants. New code should use 64-bit integers or ISO strings end to end.

Timestamp Formatter

v1.0.0

Convert timestamps between Unix, ISO 8601, UTC, and local formats. Includes live clock, example inputs, clipboard copying, and parsing tools.

Current Time

4/23/2026, 5:12:54 PM

Unix: 1776964374

Timestamp Input

Enter a timestamp to see all formats

Convert between epoch seconds, milliseconds, and human-readable ISO dates with clear timezone context. Stop guessing whether a JSON field is in seconds or ms.

Read the full guide →

Frequently Asked Questions

What is the Unix epoch?: It is midnight UTC on 1970-01-01, the reference point from which POSIX time counts seconds (ignoring leap seconds in the usual `time_t` sense). Positive values are after that instant; negative values represent times before 1970 in UTC-based libraries.
Should I store UTC or local time in databases?: Store UTC instants (or a TIMESTAMP WITH TIME ZONE that normalizes to UTC) and convert to local zones at display. Storing local civil time without offset causes ambiguous clocks during DST jumps and cross-region bugs. APIs should emit ISO 8601 with explicit offsets or `Z` for UTC.
What is ISO 8601 and why do APIs use it?: ISO 8601 strings like `2026-03-28T15:30:00Z` or `2026-03-28T10:30:00-05:00` encode calendar date, time of day, and UTC offset unambiguously. They sort lexicographically when using the same precision and offset convention—handy for logs and JSON fields.
Are Unix timestamps in seconds or milliseconds?: Unix `time_t` traditionally counts whole seconds; JavaScript `Date.now()` and many JSON APIs use milliseconds since epoch. Mixing them off by 1000× is a common bug—your tool should label units clearly. Some systems use microseconds in protobuf or logs—always read the spec.
What is the Year 2038 problem?: Signed 32-bit seconds-since-epoch overflows after `03:14:07 UTC on 19 January 2038`. Systems still using `int32` for timestamps need migration to 64-bit or string instants. New code should use 64-bit integers or ISO strings end to end.