Fork me on GitHub
#clojure-spec
<
2018-05-09
>
plins19:05:25

any suggestions where to find (libs maybe?) specs for strings contaning datetime in the ISO 8601 format

ghadi19:05:26

use java.time @plins

plins19:05:47

not sure if i expressed my self properly, but id like to validate if a strings conforms to the iso, so (s/valid? ::iso-spec "2018-05-06T13:14Z") shoud evaluate to true

ghadi19:05:49

#(try (java.time.OffsetDateTime/parse %) (catch java.time.DateTimeParseException e false))

plins19:05:00

ok! thanks

ghadi19:05:48

i wouldn't pull in any of the clj date time libraries, they all have serious defects compared to java.time

seancorfield21:05:36

@ghadi That's a bit of a sweeping statement. Could you provide a bit more specificity?

seancorfield21:05:13

(we are using clojure.java-time which is a thin wrapper around Java Time that automates the chains of conversions between (Java) types)

seancorfield21:05:58

The clj-time readme already tells people not to use it if they're on Java 8 or later -- and recommends Java Time instead, optionally using clojure.java-time as a wrapper.

ghadi21:05:20

I wouldn't even use a wrapper

seancorfield21:05:28

Fair enough. I find Java Time's raw classes to be a bit ugly if you're doing anything more than basic stuff. I find clojure.java-time's wrapper much more pleasant for more complex date/time arithmetic/manipulation.

ghadi21:05:20

clojure.java-time pulls in clj-tuple and potemkin, yuck

ghadi21:05:52

"white gloves" for interop; mostly field accessors

ghadi21:05:27

so much error-prone wrapper code... looking under the covers

ghadi21:05:35

sorry I stand by my statement

ghadi21:05:02

show me a clojure time library and I'll show you a simpler way to do it with java.time

seancorfield21:05:31

I don't see it pulling in potemkin. clj-tuple has no dependencies.

seancorfield21:05:56

My teammate is also a fan of direct Java interop rather than wrappers, but some interop code can definitely be made cleaner with wrappers (in this particular context, as we've seen in code reviews during pull requests).

mg21:05:04

It doesn’t pull in potemkin, it copies the relevant code to java-time.potemkin.*

seancorfield21:05:53

Yeah, and I'll take that little bit of potemkin code but I agree that I wouldn't want the whole thing pulled in...

ghadi21:05:08

the dep issue is minor at best

ghadi21:05:34

these libraries add nothing to your understanding of the primitives, and introduce new names for everything

ghadi21:05:50

names were very carefully chosen in java.time

gfredericks00:05:00

what are the issues with clj-time? just the parallel "adds no value over joda"?

gfredericks00:05:36

I've been using it for years and haven't noticed anything

ghadi02:05:21

joda itself had serious design issues that the authors rectified as it became java.time

ghadi02:05:45

there are a bunch of articles about the api differences of joda vs java.time

seancorfield02:05:30

@U0GN0S72R FWIW, the readme of clj-time points to Joda Time's recommendation to migrate to Java Time and that links to several articles I think.

seancorfield21:05:59

(esp. if you're unfortunately enough to have to convert back and forth with java.util.Date and/or any of the SQL date/time types!)