Add initial implementation for java time types schemas

[bsless]

Please find below an initial implementation for time schemas

Status: mature draft, at testing phase Scope: JVM, schemas, transformers, generators, JSON schema, swagger

Design:

At various points users can provide a DateTimeFormatter or pattern which will be compiled to one.

• time: contains validation code, bounds check and default formats, temporal queries and parsers
• transform: dynamically pick a user provided formatter or a default one, compile to decoder/encoder for each type.
• generator: normalize all types to long, generate and rebuild the temporal type
• json schema: provide accept methods for the formats defined by the RFC
• min/max specification is clunky but all parsing code resides in transform ns

[bsless]

@ikitommi I believe the MR is ready for review. I tried to cover everything I could think of, lmk if there are some gaps

[bsless]

Regarding the split and the addition of a bunch of namespaces, we have a few options, which I'm not a big fan of:

• keep as is: will need extensive documentation, make headache for users
• 1.ii: Will still require additional docs
• merge into respective parent namespaces with reader conditionals
• keep in separate files but use load like clojure.core does

Serialization:

• The schemas themselves are just keywords in the registry, so that's not an issue. That issue starts with min/max properties. Serializing them is not an issue, they'll be written as strings, but deserialization is a real issue I haven't figured out yet. In the beginning the parsing code as part of the core namespace to enable writing them as strings. Couple of ways to slice this:
  • bring parsers back and use them to parse the min/max properties
  • add rudimentary parsing logic separate from the transform ns just for this purpose
  • add tagged literals, #time/date "2020-01-01" (separate library?)

timex: No problem, will clean up a bit then make the change. Edit: question, change the ns fragment to timex too, or just the keyword namespace?

Thoughts?

[bsless]

I must say that after s/:time\//:timex\//g it just looks silly. It's just not aesthetic

[ikitommi]

• 1.ii - I think all the docs needed is how to add the time-schemas into registry using the malli.experimental.time namespace?
• :timex, agree, kinda like :rolex 🤣. would :jvm/date-time be better? if not, any suggestions how to handle this?

[ikitommi]

serialization, I was thinking just about values, but the schema serialization is another issue. When there is JS/CLJS supported version, support for data + parser would be good. I think we can start with the current way you proposed it.

[bsless]

regarding timex, my suggestion is to just use time

Rationale - these map to the ISO-8601 formatters: https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html

If anything, the prefix could be iso or iso-time. Barring that, just time seems most correct. It's a universal standard we're trying to satisfy

[ikitommi]

I agree :time is correct in the long run. My idea was just that we could use something else in case the schemas change (types, names, properties, formats) before CLJS/JS impl is done. Otherwise, there can be a silent breakage causing hard-to-debug problems if someone has persisted the schemas into db. With new schema name, one needs to migrate the schemas.

That said, current Temporal model doesn't seem that different:

I'm merging this now, we can post-tune this before release.

Big thanks for the PR!!

[bsless]

Awesome! I'll prepare a docs update

[ikitommi]

About the easy includes. Maybe something like:

(ns malli.experimental.time.module
  (:require [malli.experimental.time]
            [malli.experimental.time.generator]
            [malli.experimental.time.json-schema]
            [malli.experimental.time.transform]))

(defn schemas []
  (malli.experimental.time/-time-schemas))

[ikitommi]

... IMO sucks, but maybe less than the alternatives.

[bsless]

What about moving it to conditional read as part of malli.core?

[ikitommi]

that would make this non-experimental. We can do that later.

[bsless]

Would have wanted something like Emacs's advice or eval-after-load mechanism

[bsless]

Can we put it in core and gate its evaluation behind a jvm property or dynamic variable?, sort of eval-when?

[ikitommi]

Let's not do that yet. We can merge the time-schemas into the core namespaces when we drop the experimental ns part after proper test-run in projects & design verification on CLJS side. Most (if not all) the projects I've done (and seen) with malli have a custom registry already so it's easy to mount in the new time schemas.

btw, I'm still on holiday this week and mostly not reading emails, so lag in responding.