Clojure

• Type: Defect
• Status: Closed
• Priority: Major
• Resolution: Completed
• Affects Version/s: Release 1.4
• Fix Version/s: None
• Component/s: None
• Labels:

  • reader
• Environment:

  1.4-beta1, Mac OS X 10.7.3, java version "1.6.0_30"

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"

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.

java.sql.Timestamp should also print in UTC since that class doesn't keep timezone information. The print-method for Timestamp seems broken.

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"

The implementations of the print-methods for Data, GregorianCalendar and Timestamp do too much string manipulation. I suggest doing some refactoring. (Patch coming soon.)

Also, the documentation needs some updating. clojure.instant/read-instant-date, etc. mention instant-reader but I think that mechanism was generalized as data-readers.

1. 

   CLJ-928-instant-literals-for-Date-and-Timestamp.patch

   07/Feb/12 1:28 PM

   13 kB

   Steve Miner

2. 

   CLJ-928-instant-literals-for-Date-and-Timestamp-fogus.patch

   20/Feb/12 3:22 PM

   21 kB

   Fogus

• Assignee:

  Unassigned

  Reporter:

  Steve Miner

• Created:

  07/Feb/12 1:19 PM

  Updated:

  01/Mar/13 12:46 PM

  Resolved:

  24/Feb/12 3:29 PM