Missing conversions from Instant to OffsetDateTime and ZonedDateTime
dgr opened this issue · 5 comments
There doesn't seem to be a way to convert from Instant to OffsetDateTime or ZonedDateTime, even though java.time.Instant provides .atOffset and .atZone methods. This makes Instants the roach motel of clojure.java-time: easy to get in, but difficult to get out. I particularly find this issue because org.threeten.extra/Interval uses Instants as the endpoints and I'd like to convert those to ZonedDateTime. Right now, I have to use Clojure's Java interop to call .atZone directly.
Hey, how about:
user=> (j/zoned-date-time (j/instant) (j/zone-id "Europe/London"))
#object[java.time.ZonedDateTime 0x949c79c "2020-01-21T07:47:05.201549Z[Europe/London]"]
user=> (j/offset-date-time (j/instant) (j/zone-offset -3))
#object[java.time.OffsetDateTime 0x79762d73 "2020-01-21T04:48:47.084006-03:00"]
Is this what you were looking for or am I misunderstanding?
Duh. OK, that should work.
I was trying the single-arity call to zoned-date-time and was expecting something in UTC, since Instants are nominally in UTC. Yes, the docs say that Instants don't have a time zone, but if you create one by simply calling jt/instant, it displays one that is in UTC, with the time in UTC relative to the local machine time zone. Seems like Instant-to-ZonedDateTime and back should be relatively painless and not require a time zone.
user=>(jt/zoned-date-time (jt/instant))
Execution error (ExceptionInfo) at java-time.zone/zoned-date-time (zone.clj:152).
Could not convert [#object[java.time.Instant 0x1f74a83b "2020-01-21T20:03:07.347009Z"]] to class java.time.ZonedDateTime!
As an aside, the clojure.java-time docs could be improved in this regard. The clojure.java-time library takes a sometimes not obvious approach to mapping all the functionality in java.time into Clojure. In particular, just by looking at classes in java.time, it isn't clear what functions should be called.
Anyway, with all the comments about possible improvements, I'll close this. There's enough there to do what I need to do. Thanks!
Cool.
I'll create an issue for a single-arity zoned-date-time and offset-date-time constructors which would use the current zone.
Do you have a concrete improvement to the docs which you'd like applied?
Good question about concrete improvement to the docs. No, not yet. The biggest issue (if you can call it that), is that clojure.java-time is not simply a thin wrapper around java.time objects, where the user is calling the same java.time methods. Because the conversion graph is generated via macros, the parameters to various functions often display as gensym'd names which aren't helpful. You know that there's an arity-1 function there, but no idea what it might consume.
So, let me think about it and I'll try to submit pull requests that explain things better. I've switched completely to clojure.java-time in all my coding, versus cli-time, so I want to see it grow and prosper.
I second this. I spent quite some time trying to figure out how to construct a ZoneDateTime from my instants. In the API, for zoned-date-time, with 2 arities, it says
* two arguments
+ formatter and a string
+ local date-time and a zone id
+ year and month
I think we should explicitly mention the instant.