What the parser accepts
Extended and basic ISO 8601 calendar dates (2026-10-30, 20261030), week dates (2026-W44-5), ordinal dates (2026-303) and expanded years (+012026-01-01). Times can have fractions with any number of digits (beyond nine they are truncated with a warning). Offsets can be Z, ±hh:mm, ±hhmm or ±hh. RFC 9557 zone suffixes such as [Europe/Paris] are also accepted. A space instead of T is read SQL-style and labelled. 24:00:00 is normalised to the next day, and a real leap second 23:59:60 is mapped as POSIX does.
Locale-dependent dates such as 03/04/2026 are refused. They mean 4 March in the US and 3 April almost everywhere else, so any automatic choice would be a guess.
Examples to try
Offsets are kept, not discarded
An RFC 3339 timestamp records both an instant and the offset of the place that wrote it. After conversion, the outputs include a row that re-renders the instant with the original offset. You can check that a round trip reproduces the input. When the input has no offset, it is read as wall-clock time in the selected zone, and a warning names that zone.
Questions
- Why is a date without an offset flagged?
- Without an offset the text is a wall-clock time, not an instant. The converter reads it in the zone you select and says so, instead of quietly using UTC or your computer's zone.
- Does it accept a comma as the decimal separator?
- Yes, ISO 8601 allows 14:05:09,5. A warning notes that the comma was read as a decimal point.
- What about MySQL 0000-00-00?
- It is rejected with an explanation. MySQL uses it as a placeholder, and it is not a real date.