java.lang.RuntimeException: No reader function for tag object

[sooheon]

The java.time.foo objects that are returned by fns in this lib print as something like #object[java.time.Instant "0x6cc2abad" "2017-11-13T01:40:56.483Z"]

However these can't be used interactively as data because unlike java.util.Date's #inst "2017-11-13T01:41:43.571-00:00", the repl explodes when given the java.time.Instant object. Since it complains about having no reader function for #object, I guess it's a matter of extending edn to recognize #objects.

Have you encountered this problem? Is this sth for this library to tackle, or for each end user to roll their own?

[dm3]

The objects of java.time.* type are printed as any other object because core Clojure only defines the #inst print method for java.util.Date/util.Calendar/sql.Timestamp. It also only defines an #inst data reader which reads into java.util.Date by default.

Given that the Java-Time library handles Clojure integration with the java.time package, we could provide readers for the most commonly used java.time types. We could define data readers which would parse the most precise default formatted representations of time entites back into the java.time objects, e.g.:

• #java-time/instant "2017-11-10T10:00:00.000000000Z" -> java.time.Instant
• #java-time/zoned-date-time "2017-11-10T00:00:00.000000000Z[UTC]" -> java.time.ZonedDateTime
• #java-time/offset-date-time "2017-11-10T00:00:00.000000000Z" -> java.time.OffsetDateTime
• #java-time/local-date-time "2017-11-10T00:00:00.000000000" -> java.time.LocalDateTime

etc.

I don't see problems with defining those, given we namespace the data reader tags. It could potentially conflict with someone who already defined the same data readers - in that case they could continue to use the previous version of the library.

Printing the java.time types into their "readable" representations is trickier. This is a significant change in the behaviour which might cause breakage. However, I'm pretty sure many people would love to be able to treat the java.time as EDN-serializable objects so I'm interested in introducing either:

• a new alpha version of Java-Time with the data readers and print-methods in it or
• a complementary optional dependency (including the above functionality)

what do you think? Would you be willing to contribute an implementation?

[magnars]

If you're still interested, here's a library that adds readers and printers for java.time classes: https://github.com/magnars/java-time-literals

[henryw374]

And another.. https://github.com/henryw374/time-literals