Same instant
Calculation example: 2026-01-15T10:00:00+02:00 equals 2026-01-15T08:00:00Z.
In-depth practical guides
Separate calendar dates, local times and instants before sorting records or converting to UTC.
Updated :
Publication, effective and access dates have different roles. Retaining role and precision prevents a misleading chronology; normalisation does not certify the producer’s clock.
Record field, language, convention and role. Keep 2026-10 as a month; do not invent a day or hour.
Z or +02:00 locates an instant. Local time needs a zone and date-specific rules; a country or your computer’s setting is insufficient.
03/04/2026 needs the producer’s convention. Clock changes can repeat or skip local times; record uncertainty instead of silently choosing.
Keep original, normalised value, zone, offset and rule version. Sort determined instants separately from calendar dates.
Processed in your browser; values are not sent to the server. One value per line, up to 100 lines. Examples are calculation cases.
Supported: YYYY-MM-DD, partial year or month, and timestamps with seconds and Z or ±HH:MM offset. Fractions of 1–9 digits are retained. Local times are not converted; leap seconds need separate treatment. Input order is preserved.
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
Calculation example: 2026-01-15T10:00:00+02:00 equals 2026-01-15T08:00:00Z.
2026-01-15 is a calendar date. Midnight UTC would add information the source never supplied.
Only when evidence establishes that it is the zone of the event. The reader’s setting does not establish the source’s local time.
RFC 3339 uses it for an unknown local offset when UTC time is known. Preserve that status instead of treating it as evidence of a local zone.
TOOLS / REGISTERS
Keep original, normalised value, zone, offset and rule version. Sort determined instants separately from calendar dates.