...
- #@ISO8601-STRING reader macro
- codename, swear-date
- calls pluggable parser fn
- extension point is via bindable var
- default parser
- option 1: uses Joda to parse, returns java.util.Date
- throws exception referencing Joda if Joda not on classpath
- option 2: like 1, but uses
- uses JDK 6 java.xml.bindDatatypeConverter
- how compatible is XML dateTime with ISO8601? Schema spec says "inspired by" which does not inspire confidence
- option 1: uses Joda to parse, returns java.util.Date
- print java.util.Date, Joda DateTime in this formatbut not Java date stuff (makes promises we don't want / can't fulfill)swear-date format
- what other classes?
Q & A
- Would Clojure apps now all depend on Joda? No. Joda is only a requirement for building Clojure itself. (Maven's "provided" dependency scope keeps the static tools at bay, and Joda is only loaded dynamically if present.)
- What about localization, time zones, etc? These are not part of the semantics of an instant. You can choose a local representation that complects this, but you should not assume it will be conveyed by print/read.
- What about types that lack resolution to match what ISO8601 can say? Sorry! Bind an instant reader that produces a better type of live with your impoverished local rep.
- It would be cool if there were a library for manipulating instants with convenient Clojure syntax. Darn straight. Let's have a contrib for this.
Issues
- would be nice to return something meaningful given time part only
- JDK 5 has no ISO8601 parser
- JDK 6 has only in javax.xml.bind.DatatypeConverter
- Using Joda for parse introduces dep into Clojure
- Print/read veracity requires matching parsers
- is this a real issue?
- is flexibility allowing difference not a feature?
- SDH liking this flexibility less, still on fence
- SDH liking this flexibility less, still on fence
- Others I'm sure
...