`current_timestamp` also returns something like `2025-06-15 19:50:50` while the docs state that it is ISO 8601. Except that this is not ISO 8601 due to the T missing in the middle. This has caused some headaches due to different formats of JS's `.toISOString()` and SQLite's `current_timestamp`. The datetime column is basically only for documentation. I wish they had some timestamptz type which rejects insertions containing invalid datetime formats.
You probably mean RFC3339, which overlaps with ISO 8601 and allows this. But the docs don't mention that RFC and only reference the ISO standard.
You can compare the formats here: https://ijmacd.github.io/rfc3339-iso8601/
You're absolutely right, I confused it with RFC3339. ISO8601 suggests that the 'T' is optional, but only in the sense of leaving it out... and fails to provide any actual examples of doing so.
The amount of handwaving in ISO8601 could turn a windmill, though in this respect RFC3339 is not much better. The ABNF clearly shows "T" (case-insensitive) as the only separator, but immediately afterward gives us this:
> NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
Separated by (say) whatever the hell you want apparently. I'm getting bruises on my face from all the palming.
That is not true. I refer you to a PDF copy of ISO 8601[1] (a 2016 working draft copy, but still representative). Within section "4.3.2 Complete Representations" it reads as follows:
> The character [T] shall be used as time designator to indicate the start of the representation of the time of day component in these expressions. The hyphen [-] and the colon [:] shall be used, in accordance with 4.4.4, as separators within the date and time of day expressions, respectively, when required.
> NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard.
They then show examples which clearly show that they mean you can not-include the T, but you CANNOT substitute T for a space.
Unless I am incorrectly reading the document or unaware of a further section indicating the further allowance of substituting a T for a space, you cannot swap T for space according to the standard.
1 - https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
Yep, I got it confused with RFC3339, which starts off with a precise spec, then lays out vague exceptions in the prose like using a space. All I want for xmas this year is a proper datetime specification, from anyone but ISO (who still doesn't seem to understand that software engineers are never going to pay for a spec).
ISO8601 is a collection of different formats, and using a space instead of a ‘T’ is one of the allowed variations. I’m not sure anything implements the full spec perfectly.