Progress update on the Clojure(Script) date-time libraries

[henry_w]

An update on what’s happened since I gave a talk last April.

Progress update on the Clojure(Script) date-time libraries

AMA here, thanks

[borkdude]

Thanks for the overview.

I’ve added most java.time classes to babashka, since I couldn’t figure out what the date-time library should be to provide as a built-in. But now that it supports libraries via the --classpath option, such a library could be made in user-space.

Short demo:

$ pst.clj
#!/usr/bin/env bb

(def now (java.time.ZonedDateTime/now))
(def LA-timezone (java.time.ZoneId/of "America/Los_Angeles"))
(def LA-time (.withZoneSameInstant now LA-timezone))
(def pattern (java.time.format.DateTimeFormatter/ofPattern "HH:mm"))
(println (.format LA-time pattern))

$ pst.clj
03:17

[henry_w]

Sounds interesting, I’ve been meaning to have a look at Babashka

[henry_w]

I think cljc.java-time will work on babashka with a few tweaks: I raised this issue https://github.com/henryw374/cljc.java-time/issues/10

[henry_w]

the few tweaks have been made! version 0.1.11 (on clojars https://clojars.org/cljc.java-time) now works on babashka

user=> (require '[cljc.java-time.zone-id :as z])
user=> (z/of "America/Los_Angeles")
#object[java.time.ZoneRegion 0x4d87cb0a "America/Los_Angeles"]
user=> (require '[cljc.java-time.local-date :as ld])
user=> (ld/now)
#object[java.time.LocalDate 0x4045d556 "2020-05-29"]

[ikitommi]

Any update on the time-libraries? Would need a light weight time abstraction for malli, supporting Clojure/Script. Something small and simple, compatible with java.time. Could be just a standalone malli.time namespace, but could be a 3rd party lib, if such exists. In JSON Schema, there are only date-time, date and time.

Requirements:

• basic types (java.time & ??? for cljs)
• type and range validation
• parsing from strings (+ formats)
• small js bundle size

[Webdev_Tory]

Is tick too big? It’s our favorite on our projects.

[ikitommi]

Tick is awesome, and light on the JVM but sadly, it uses js-joda with cljs, which is too big as a library dependency. Malli is built DCE in mind, the bundle sizes start from few kilos gzipped. js-joda is 43kb, tick totals 50kb.

here’s a sample report using shadow-cljs:

If there is way to slim down tick on cljs, I’m all s

[henry_w]

Ok so I have a work in progress which means DCE will work for js-joda - see Cljc.java-time will drop all npm/foreign-lib dependencies. It’s taken ages, but all the bits are there - I just need to finish it off… which I’ll try to do in the next couple of weeks or so.

So to be clear, although DCE works on it, (so if you don’t use any of the lib, nothing gets included in your js bundle) - because of the nature of the library, if an end user does use some of jsjoda, they end up pulling in most of the lib. It’s just the nature of js-joda that it’s a bit like a ball of string - ie start pulling on one bit and the rest follows. So not the best outcome I could have hoped for.

Longer term, the new platform dates for JS should be a good solution - in that cljc.java-time could use that and be dependency free - see https://github.com/henryw374/cljc.java-time/wiki for some thoughts on that, including the fact that the api is not completely 1:1 with java.time.

[Webdev_Tory]

How did you make this bundle size report? I’ve been wanting to do that!

[orestis]

That’s a standard shadow-cljs thing: https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report