Kevin Downey
added a comment - 04/Nov/11 1:37 PM using a bindable var for a read time setting is kind of a drag stuff like:
(binding [*instant-reader* some-other-instant-reader]
#@2011-11-04T14:42Z)
will not have the desired effect, so then what are the use cases for the bindable var? should the repl bind it? should the compiler?

It seems like it would be nice to have time-delta literals as well. My usage cases deal more often with time-deltas applied as intervals or offsets in time. I presume the current scheme doesn't allow for that but could be adjusted. Is that outside of the scope of this discussion?

Aaron Brooks
added a comment - 05/Nov/11 9:55 AM It seems like it would be nice to have time-delta literals as well. My usage cases deal more often with time-deltas applied as intervals or offsets in time. I presume the current scheme doesn't allow for that but could be adjusted. Is that outside of the scope of this discussion?

Rich Hickey
added a comment - 06/Nov/11 10:31 AM > UTC at the door.
No. Offsets are not localization, just arithmetic.
>idiom for dynamically loading code based on whether Joda on classpath
We'll need more explicit mechanisms for determining the programmatic representation. Dynamic Joda is just to avoid Joda as hard implementation dep.
> People using ant will have to configure path locally to include Joda.
People using ant = me.

This patch implements instant literals of the form #@yyyy-mm-ddThh:mm:ss.fff+hh:mm using only classes available in the JRE.

clojure.instant provides instant-readers producing instances of three different JDK classes. These functions accept a string representing a timestamp See (doc clojure.instant/parse-timestamp) for details.

read-instant-date (java.util.Date)

read-instant-calendar (java.util.Calendar)

read-instant-timestamp (java.sql.Timestamp)

By default *instant-reader* is bound to read-instant-date.

print-method and print-dup are provided for all three types.

Rough bits include:

I'm not yet certain about the exact public interface of clojure.instant. It's clear that read-instant-* need to be visible. It also seems likely that parse-timestamp and validated could usefully support alternate implementations for *instant-reader*.

fixup-offset and fixup-nanos are ugly warts necessitated by Java's pathetic built-in support for dates and times (possibly exacerbated by my own misunderstandings of the same).

Unit tests are very basic. For example, I'm not testing validated except in the good case where everything is valid.

Ben Smith-Mannschott
added a comment - 12/Nov/11 3:10 PM - edited This patch implements instant literals of the form #@yyyy-mm-ddThh:mm:ss.fff+hh:mm using only classes available in the JRE.
clojure.instant provides instant-readers producing instances of three different JDK classes. These functions accept a string representing a timestamp See (doc clojure.instant/parse-timestamp) for details.

read-instant-date (java.util.Date)

read-instant-calendar (java.util.Calendar)

read-instant-timestamp (java.sql.Timestamp)

By default *instant-reader* is bound to read-instant-date.
print-method and print-dup are provided for all three types.
Rough bits include:
I'm not yet certain about the exact public interface of clojure.instant. It's clear that read-instant-* need to be visible. It also seems likely that parse-timestamp and validated could usefully support alternate implementations for *instant-reader*.
fixup-offset and fixup-nanos are ugly warts necessitated by Java's pathetic built-in support for dates and times (possibly exacerbated by my own misunderstandings of the same).
Unit tests are very basic. For example, I'm not testing validated except in the good case where everything is valid.
See also https://github.com/bpsm/clojure/commit/753f991151847df53d624f7c09b7113cd2321793
I've made a few trivial fixes to doc strings, visible on my github branch. Those changes will be included when I re-roll the patch it to incorporate any feedback.

Oddly, I made another case for this. My bad. Attached is the updated patch based off of Ben's work. This patch is merged into the tagged literal feature as implemented in v1.4-alpha4. I also fixed a fence-post error and very minor doc problems. The parser currently defaults to constructing j.u.Date instances of the following form:

Fogus
added a comment - 21/Jan/12 9:11 AM Oddly, I made another case for this. My bad. Attached is the updated patch based off of Ben's work. This patch is merged into the tagged literal feature as implemented in v1.4-alpha4. I also fixed a fence-post error and very minor doc problems. The parser currently defaults to constructing j.u.Date instances of the following form:

Stuart Sierra
added a comment - 27/Jan/12 8:46 AM - edited 2 problems:
1. You can't specify an alternate inst reader in data_readers.clj. Doing so causes an opaque error when Clojure starts. This is a flaw in CLJ-890
2. *data-readers* is intended to be a map of symbols to Vars, not symbols to functions. This doesn't really matter.

Stuart Sierra
added a comment - 27/Jan/12 9:24 AM New patch CLJ-871-with-defaults.patch.
Fixes problems described in previous comment by adding default-data-readers which can be overridden by *data-readers*. Also adds documentation for *data-readers*.

Steve Miner
added a comment - 01/Feb/12 2:25 PM divisible? and indivisible? should be normal functions, not macros. They're used only in leap-year? – it would be pretty simple to use zero? and mod? directly there.