Allow selecting date/date-time backend

[jcgruenhage]

chrono is nice, but the ecosystem also has time and jiff to offer. At the time of writing, chrono has 557M downloads, time beating that with 665M, and jiff trailing behind with 106M. Each of these is clearly used often enough though, that there's going to be people who want to use a specific one of these three to match the rest of their stack.

I'd be willing to implement this myself, but before I spend the time, is this something that you're interested in?

[ahl]

If this is something you'd use, then: sure. If it's something you merely think might be useful to someone... I think we'd be less interesting in taking and maintaining that change.

[jcgruenhage]

I am interested in using it, in fact, I am already using it, but right now through GenerationSettings::with_conversion:

    let mut settings = GenerationSettings::default();

    // Map OpenAPI `format: date-time` → `jiff::Timestamp` and
    // `format: date` → `jiff::civil::Date`. Typify checks the conversion
    // list before its built-in chrono mapping in `convert.rs`, so this
    // overrides the chrono default without a fork. The wire shape stays
    // RFC 3339 / ISO 8601 strings — only the Rust types change.
    settings.with_conversion(
        SchemaObject {
            instance_type: Some(SingleOrVec::Single(Box::new(InstanceType::String))),
            format: Some("date-time".to_string()),
            ..Default::default()
        },
        "::jiff::Timestamp",
        [TypeImpl::Display, TypeImpl::FromStr].iter().copied(),
    );
    settings.with_conversion(
        SchemaObject {
            instance_type: Some(SingleOrVec::Single(Box::new(InstanceType::String))),
            format: Some("date".to_string()),
            ..Default::default()
        },
        "::jiff::civil::Date",
        [TypeImpl::Display, TypeImpl::FromStr].iter().copied(),
    );

This does feel a bit hacky though, and leaves chrono as a build dependency.

[ahl]

That seems like a pretty nice solution. I think chrono is only a test dependency--is that a problem?

[jcgruenhage]

It's only a build dependency, which is pulled in by enabling the chrono feature on schemars. Not too bad, but feels off. I'll spend some time to look at how this can be improved.

[jcgruenhage]

A minimal variant that allows me to drop chrono from my build dependencies would look like this:

diff --git a/Cargo.toml b/Cargo.toml
index af2e14afed..6d9f235934 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -48,7 +48,7 @@
 regress = "0.11.1"
 reqwest = { version = "0.13.3", default-features = false, features = ["json", "query", "stream"] }
 rustfmt-wrapper = "0.2.1"
-schemars = { version = "0.8.22", features = ["chrono", "uuid1"] }
+schemars = { version = "0.8.22", features = ["uuid1"] }
 semver = "1.0.28"
 serde = { version = "1.0.226", features = ["derive"] }
 serde_json = "1.0.149"
diff --git a/example-macro/Cargo.toml b/example-macro/Cargo.toml
index 361b0c0cb8..0265c327b9 100644
--- a/example-macro/Cargo.toml
+++ b/example-macro/Cargo.toml
@@ -9,6 +9,6 @@
 chrono = { version = "0.4", features = ["serde"] }
 progenitor = { path = "../progenitor" }
 reqwest = { version = "0.13.3", features = ["json", "query", "stream"] }
-schemars = { version = "0.8.22", features = ["uuid1"] }
+schemars = { version = "0.8.22", features = ["chrono", "uuid1"] }
 serde = { version = "1.0", features = ["derive"] }
 uuid = { version = "1.23", features = ["serde", "v4"] }

That's going to be a breaking change for anyone who derives schemars::JsonSchema on an OpenAPI spec that includes date or date-time types, typically through derives = [schemars::JsonSchema] in generate_api! or GenerationSettings::with_derive("schemars::JsonSchema"), but doesn't enable the chrono feature on schemars themselves.

I'd say that the chrono feature on schemars is their responsibility, not ours. The README already instructs users to add chrono to their dependencies if they have date or date-time formats in their spec. There should be a similar instruction telling them to depend on schemars if they add the derive, and to enable chrono on schemars if their spec contains date or date-time formats.

[jcgruenhage]

I'd also be okay with contributing a more extensive variant that doesn't require the GenerationSettings::with_conversion bit, but that means patching both typify and progenitor. Which one do you prefer?

[ahl]

Let's just take this diff to the Cargo.toml files (and you can remove the "uuid1" dep in the root Cargo.toml). I'm fine breaking consumers if they're relying on our mistaken use of a feature we don't need (and we'll release it in a semver incompatible version).

[jcgruenhage]

Cool, thanks. PR coming in a couple of minutes.