(t/instant? (.toInstant #inst "2020-09-26T23:08:27.619-00:00"))
=> true
(t/instant? (t/instant #inst "2020-09-26T23:08:27.619-00:00"))
=> true
This works: (t/format "<http://yyyy.MM|yyyy.MM>.dd" (t/zoned-date-time 2015 9 28))
=> "2015.09.28"
but I can't find a way to convert a datomic db.type/instant to a zoned-date-time.
There must be a more straightforward way to format datomic datetime values.
user=> (t/format "dd/MM/yyyy" (t/zoned-date-time #inst "2020-09-26T23:08:27.619-00:00" (t/zone-id "UTC")))
"26/09/2020"
user=>
(or whatever TZ you need there)
Although if you're dealing with #inst
which I believe are just regular java.util.Date
objects, this should work (without clojure.java-time
at all):
user=> (let [f (java.text.SimpleDateFormat. "dd/MM/yyyy")]
(.format f #inst "2020-09-26T23:08:27.619-00:00"))
"26/09/2020"
user=>
Yup, Datomic docs say it's just a java.util.Date
:
:db.type/instant instant in time java.util.Date #inst "2017-09-16T11:43:32.450-00:00"
@seancorfield Thanks very much! I've confirmed that both approaches work as expected with an #inst returned from datomic.
I've learned a lot here, both by dipping my toes into the clojure.java-time
and tick
libraries, and getting a more practical sense of how java interop works through your example.
@nando I meant something like this (sorry, was on a phone earlier):
(let [d #inst"2020-10-03T12:18:02.445-00:00"
f (-> (java.time.format.DateTimeFormatter/ofPattern "dd/MM/yyyy")
(.withZone (java.time.ZoneId/systemDefault)))]
(.format f (.toInstant d)))
I avoid java.text.SimpleDateFormat because it’s the “old” way and it’s not thread-safe
I think what sean posted is nearly the equivalent, except he coerces to a zoned date time instead of specifying the zone in the formatter
but I’m not familiar with clojure.java-time, I just use java.time directly
@favila I see what you originally meant evaluating
(let [d #inst"2020-10-03T12:18:02.445-00:00"
f (-> (java.time.format.DateTimeFormatter/ofPattern "dd/MM/yyyy")
(.withZone (java.time.ZoneId/systemDefault)))]
(.format f d))
The same error is produced without the date being wrapped in a .toInstant call.
In what type of use case would the fact that SimpleDateFormat is not thread safe produce an unexpected result, particularly in the context of a web application?
Def the format object and then use it in functions running in my tools threads
*multiple
There are a few strata of Java date systems
The oldest is Java.util.date objects. The newest is Java.time.*, which represents instants as Java.time.Instant objects instead.
There are some in between that aren’t worth learning anymore
Yup, going via Java Time is definitely the safest route and the best set of APIs to learn. At work, over the past decade we've gone from java.util.Date
to date-clj
(date arithmetic for that old Date
type), to clj-time
(wrapping Joda Time), to Java Time (with clojure.java-time
in some parts of the code and plain interop in a lot of places). Converting java.util.Date
to java.time.Instant
and doing everything in Java Time is a bit painful/verbose, but you can write utility functions for stuff you need frequently to hide that interop/verbosity.