instant literal
Steve Miner
The documentation is out of date for clojure.instant/read-instant-date, etc. It mentions *instant-reader* but I think that mechanism was generalized as *data-readers*. Same issue for read-instant-calendar and read-instant-timestamp.
> clojure.instant/read-instant-date
> Bind this to *instant-reader* to read instants as java.util.Date.
I'm a little confused by the doc for parse-timestamp which says in part:
> Unlike RFC3339:
>
> - we only consdier timestamp (was 'date-time')
> (removed: 'full-time', 'full-date')
> - timestamp can elide trailing components
> - time-offset is optional
>
Typo: "consdier" should be "consider". I'm guessing the (was 'date-time') and (removed: ...) phrases are developer comments that should be removed altogether.
The default #inst returns a java.util.Date. Date is always in UTC, and doesn't know about time zones, but the implementation of the print method always renders it in the default time zone. For example,
user=> #inst "2012Z"
#inst "2011-12-31T19:00:00.000-05:00"
I'll admit that it's nitpicking, but I find that offset disconcerting. I'd much prefer that it print in UTC with an offset of -00:00 to convey the appropriate semantics for a java.util.Date. RFC3339 says:
> 4.3. Unknown Local Offset Convention
>
> If the time in UTC is known, but the offset to local time is unknown,
> this can be represented with an offset of "-00:00". This differs
> semantically from an offset of "Z" or "+00:00", which imply that UTC
> is the preferred reference point for the specified time.
Would you accept a patch to print java.util.Date in UTC as -00:00? I'll file a ticket and provide a patch if there's an agreement on this.
The printing of java.sql.Timestamp looks broken to me.
user=> (binding [*data-readers* {'inst #'clojure.instant/read-instant-timestamp}] (read-string "#inst \"2012Z\""))
#inst "2011-12-31T19:000000000000000-05:00"
user=> (binding [*data-readers* {'inst #'clojure.instant/read-instant-timestamp}] (read-string "#inst \"2012-01-01T01:23:45.678+00:00\""))
#inst "2011-12-31T20:267800000000000-05:00"
user=> (java.sql.Timestamp. 0)
#inst "1969-12-31T19:000000000000000-05:00"
I'd be surprised if it makes a difference, but just in case: I'm testing on Mac OS X 10.7.3.
~$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12-404-11M3614)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03-404, mixed mode)
Steve Miner
steve...@gmail.com