ISO 8601 and RFC 3339: offsets, UTC and date-only values

Use an explicit instant

Z indicates UTC; a numeric offset relates a displayed calendar time to UTC. Different displays can describe the same instant.

For an API timestamp, include the offset and agreed fractional precision. A string without an offset needs a separate timezone agreement.

2024-01-01T00:00:00Z
2024-01-01T08:00:00+08:00
These represent the same instant.

An offset is not a named timezone

An offset such as +01:00 describes that instant’s offset. An IANA zone such as Europe/London describes rules that can change by date.

Store a named zone for recurring local schedules. A fixed offset alone cannot express a city’s daylight-saving transitions.

Keep dates separate from datetimes

A birthday or billing date may be a calendar date rather than an instant. Assigning midnight in an arbitrary zone can shift its displayed day elsewhere.

JavaScript date-only and offset-free datetime parsing have different standardized behavior. Nav Tools asks for its documented timestamp or datetime format instead of guessing that business meaning.

Compare instants after parsing

Lexicographic order is reliable only for a carefully normalized representation. Mixed offsets or varying precision can defeat a plain string sort.

Convert to comparable instants for chronology, or normalize to UTC with a consistent format. Keep local calendar dates as dates when that is the domain model.