Why doesn't Jiff support automatically parsing datetimes like 2025-03-10 02:00:59 -0500?

[th1000s]

Currently jiff can parse 2024-03-10 02:00:59-0500, but not 2024-03-10 02:00:59 -0500 (space separated TZ). Using jiff v2.11, the string is from the chrono comparison, tested on Linux with use jiff::Timestamp;, then .parse(). This returns Err(parsed value '2024-03-10 02:00:59', but unparsed input " -0500" remains (expected no unparsed input)).

This format is e.g. described in git log(1):

--date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like format. The differences to the strict ISO 8601 format are:

• a space instead of the T date/time delimiter
• a space between time and time zone
• no colon between hours and minutes of the time zone

It is used by e.g. chrono and in GNU coreutils stat, and personally I find it more readable. The other two deviations (T, no colon) already work, presumable because they are/were in the standard. A space separating the TZ does not seem ambiguous to me.

Also, while reading about the topic on Wikipedia I noticed that the Unicode minus (− vs ASCII -) is also not parsed.

[BurntSushi]

Thanks for the issue/question!

So first and foremost, as documented, Jiff follows the Temporal ISO 8601 grammar. It is based on ISO 8601, but doesn't support all of it and does support some extensions that make it also compatible with RFC 3339 and RFC 9557. It's a hybrid format that's meant to cover most use cases. Jiff stays pretty strictly with what Temporal specifies. I'm very firmly opposed to expanding to beyond what Temporal supports because of negative second order effects. The format you ask about is not supported by Temporal's grammar.

Secondly, 2024-03-10 02:00:59 -0500 is not ISO 8601. It's not actually anything at all. It's not valid RFC 3339 or RFC 9557. I just double checked all three (including my copy of ISO 8601), and it's just not in any of them. RFC 3339 does permit using a space instead of a T, but ISO 8601 doesn't. And neither permit a space between the datetime and the UTC offset. So the fact that git log is calling this "iso" or "iso8601" is just factually wrong. My guess is that someone made a mistake and fixing it is more trouble than it's worth. It's probably why they also have iso-strict and iso8601-strict options.

Thirdly, it's not hard to use Jiff's strftime support to parse what you want:

use jiff::Timestamp;

fn main() -> anyhow::Result<()> {
    let ts = Timestamp::strptime(
        "%Y-%m-%d %H:%M:%S %z",
        "2024-03-10 02:00:59 -0500",
    )?;
    assert_eq!(ts.to_string(), "2024-03-10T07:00:59Z");
    Ok(())
}

So from my perspective, yes, you don't get automatic parsing for free. But there is a very easy work-around if you need to support that specific format.

Also, while reading about the topic on Wikipedia I noticed that the Unicode minus (− vs ASCII -) is also not parsed.

Yeah this is intentional. See tc39/ecma262#3334 and tc39/proposal-temporal#2856