Instants describe an instant in time, which is usually represented in UTC by default but can be represented in other time zones or offsets too (if you apply the right apis)

https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html says useful things about all this

Thanks that is helpful. I note that an instant is represented in the repl as #inst "2022-10-24T03:28:10.110-00:00" I am theorizing that that trailing -00:00 will always be -00:00.

(when represented in “pure” instant form)

An instant literal is just a serialization format

The data that gets serialized that way could be in any number of formats

A common one is a java until Date, which is what instant literals deserialize to by default

The default serializers always serialize as utc, regardless of the time zone of the Date object

Ok - thanks @U0NCTKEV8

Adding to this, please note that (type #inst "2022-10-24T03:28:10.110-00:00") is java.util.Date - you probably want to use the improved java.time.Instant since its semantics are explicitly defined in terms of UTC-SLS per the docs @U064X3EF3 posted above.

Both should print as Clojure instants and respond true to inst?

Thanks @U064X3EF3 and thanks everyone for the very helpful pointers and background!

That's how hash maps work. A hash function will inevitably produce collisions sooner or later, for all sorts of values of all sorts of types.

Wiki has a good description with informative diagrams on how hash collision resolution works: https://en.wikipedia.org/wiki/Hash_table#Collision_resolution

BTW, not that important, but in your example that resulting map's type is actually an array map - so hashes aren't used at all there.

Right! It’s small enough. OK, I see. So basically the idea is: hash and hope that there’s no collision. If there is a collision, perform additional conflict resolution.

Yep.

And for persistent hash maps, not array maps, nil keys are handled explicitly

Clojure's hash-map implementation uses linked lists for all keys that happen to have the same hash function value, so performance can be bad if your application ends up colliding on hash keys a lot.

Clojure's hash function in version 1.6.0 was changed because the hash function for vectors and other collections collided more often than the Clojure developers wished, for certain commonly used sets of keys, e.g. 2-element and 3-element vectors of integers used as map keys.

I was reading up on this, and the hashCode to hash with murmur3 move, which lead me to play around with the behaviour of hash. I get that it’s about minimizing the collisions now, not eliminating them. Incidentally, does this mean that = behaves in a way similar to hashed collection then? I.e., some kind of optimism based on hash, with more exotic stuff under certain circumstances.

@U06B8J0AJ I can imagine a performance optimization of = between collections that, if the hash functions of both collections were already computed (they might not have been -- they are computed on demand, not when the collection is first created), and they were different, then quickly return false from =. However, no such optimization would be (correctly) possible if the hash functions were the same.

Clojure's = does not implement such an optimization today, if I recall correctly.

= for many collections does quickly return false if their number of elements are different.

Right, but I guess I should still consider = to be an O(n) operation for all intents and purposes then. I can see how this makes memoizing correctly, at the correct place and time, an artform.

trivia: there used to be an infinite pessimization because of that shortcut: (= [] (range)) would never terminate, while (= (range) []) would return false. This appears to have been fixed in Clojure 1.11

It works somewhat properly in my REPL - in a plain clj one. "Somewhat" only because the prompt for user's input appears in the middle of printing. But pprint is not atomic, so that's fine. So maybe the behavior that you see is caused by your particular REPL.

almost certainly related to flushing in the output stream

Wouldn't subsequent prints then flush the previous ones? In the OP's example, the output is straight up missing.

does this work better?

(defn tap-fn [x] (pprint x) (flush))

just guessing... would be good to know what repl you're using too

the flush did not change the output. About the repl:

;; Connected to nREPL server - 
;; CIDER 1.4.0 (Kyiv), nREPL 1.0.0
;; Clojure 1.11.1, Java 17.0.4

might want to ask in #C0617A8PQ or #C17JYSA3H - seems like I/O shenanigans

indeed, just tried on a repl open by "clj" and it has the desired output

this has come up before, if I recall the enqueue method actually checks to make sure the class of the passed in object is marked as synthetic (which it is if generated by sam converting a lambda in java), but there is nothing in clojure that generates such a thing

when I reifythe JobLambda Interface an error rise Please provide a lambda expression (e.g. BackgroundJob.enqueue(() -> myService.doWork()) instead of an actual implementation.

exactly

they want it to be a java lambda because of how they do bytecode inspection

https://clojurians.slack.com/archives/C03S1KBA2/p1659716676694029 is some previous discussion

yeah, he end up using quartz and Im trying to run away from it.

looks like they have a jobsrequest interface thing https://www.jobrunr.io/en/documentation/background-methods/#via-a-jobrequest

seans not to work

(BackgroundJobRequest/enqueue
    (reify JobRequest
      (getJobRequestHandler [this]
        (println "test"))))
test
Execution error (NullPointerException) at org.jobrunr.jobs.JobDetails/<init> (JobDetails.java:27).
null

not using it now, but we briefly had it as part of a service before html sanitizing became someone else's responsibility

it's just another java library

Ya, I am using it https://github.com/cljdoc/cljdoc/blob/master/src/cljdoc/render/sanitize.clj. Happy to answer any questions you might have.

We use JSoup, but our sanitizer is very aggressive and removes most of the markup, attributes and all styles

but good to know about this one!