Clojurians Log v2

Last time I had a weird bug like that, it was because I had inadvertently modified a jar file under ~/.m2 (using Vim -> jump to definition on a library function opens up the JAR, saving modifies the zip file in-place), so I'd try rm -rf ~/.m2/repository and see if that fixes it.

(Or mv ~/.m2/repository ~/m2-backup or the like if you want to be able to investigate further.)

Clearing my ~/.m2/repository and rerunning the repl worked. I am almost certain it was vim jump to definition as I regularly peek. I need to be much more careful when doing so. Unfortunately, I didn’t backup as I got to fixated on your first message. 🤦

Thank you so much everyone for jumping in to help, I greatly appreciate it!

Opening to peek, and sometimes even changing the code and eval-ing the new version, are very powerful and useful tools. But, yeah, the habit of :wq! for closing a file can be a bit of a hindrance here.

On my laptop

$ lein repl
Warning: environ value /opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home for key :java-home has been overwritten with /opt/homebrew/Cellar/openjdk/24.0.2/libexec/openjdk.jdk/Contents/Home
INFO  2025-08-19 11:45:59,627-0600 [main] org.eclipse.jetty.util.log: Logging initialized @11935ms to org.eclipse.jetty.util.log.Slf4jLog
nREPL server started on port 56432 on host 127.0.0.1 - 
REPL-y 0.5.1, nREPL 1.0.0
Clojure 1.11.1
OpenJDK 64-Bit Server VM 24.0.2
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

smarts.core=> (def a #inst "2024-10-10T00:00:01.000Z")
#'smarts.core/a
smarts.core=> (= a #inst "2024-10-10T00:00:01.000Z")
false

On my coworkers laptop

$ lein repl
Warning: environ value /opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home for key :java-home has been overwritten with /opt/homebrew/Cellar/openjdk/24.0.2/libexec/openjdk.jdk/Contents/Home
INFO  2025-08-19 10:32:07,426-0700 [main] org.eclipse.jetty.util.log: Logging initialized @6525ms to org.eclipse.jetty.util.log.Slf4jLog
nREPL server started on port 50151 on host 127.0.0.1 - 
REPL-y 0.5.1, nREPL 1.0.0
Clojure 1.11.1
OpenJDK 64-Bit Server VM 24.0.2
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

smarts.core=> (def a #inst "2024-10-10T00:00:01.000Z")
#'smarts.core/a
smarts.core=> (= a #inst "2024-10-10T00:00:01.000Z")
true

This irregularity is causing issues with my ability to run our unit tests 😬

what is (type a) on each machine?

Just tried the same thing with clj

$ clj
Clojure 1.11.1
user=>  (def a #inst "2024-10-10T00:00:01.000Z")
#'user/a
user=> a
#inst "2024-10-10T00:00:01.000-00:00"
user=> (= a #inst "2024-10-10T00:00:01.000Z")
true
user=>

wild hunch: there’s something in the profiles.clj that adds something that helpfully installs some kind of java-time class for the #inst reader tag

On both machines

smarts.core=> (type a)
java.util.Date

i’d try to start removing layers

(let [a (clojure.instant/read-instant-date "2024-10-10T00:00:01.000Z")
      b (clojure.instant/read-instant-date "2024-10-10T00:00:01.000Z")]
  (= a b))
true

I would definitely compare your System properties in the two contexts

user.timezone

check if *data-readers* has any extra bindings

something like (pprint (bean #inst "2024-10-10T00:00:01.000-00:00")) might help reveal the underlying fields better too.

Here is some **perhaps interesting context

smarts.core=> (def a #inst "2024-10-10T00:00:01.000Z")
#'smarts.core/a
smarts.core=> (clojure.test/is (= a #inst "2024-10-10T00:00:01.000Z"))

FAIL in () (form-init18247573092840804319.clj:1)
expected: (= a Wed)
  actual: (not (= #inst "2024-10-10T00:00:01.000-00:00" Wed))
false

where did Wed come from

recreate the (= a #inst) thing and then throw each one through bean and see if you get anything?

(bean (clojure.instant/read-instant-date "2024-10-10T00:00:01.000Z"))
{:day 4,
 :date 10,
 :time 1728518401000,
 :month 9,
 :seconds 1,
 :year 124,
 :class java.util.Date,
 :timezoneOffset 0,
 :hours 0,
 :minutes 0}

I got the same result for

(let [a (clojure.instant/read-instant-date "2024-10-10T00:00:01.000Z")
      b (clojure.instant/read-instant-date "2024-10-10T00:00:01.000Z")]
  (= a b))

smarts.core=> (pprint (bean #inst "2024-10-10T00:00:01.000-00:00"))
{:class clojure.lang.Symbol, :name "Wed", :namespace nil}

smarts.core=> (pprint (bean #inst "2024-10-10T00:00:01.000-00:00"))
{:day 3,
 :date 9,
 :time 1728518401000,
 :month 9,
 :seconds 1,
 :year 124,
 :class java.util.Date,
 :timezoneOffset 420,
 :hours 17,
 :minutes 0}

smarts.core=> (clojure.test/is (= (bean a) (bean #inst "2024-10-10T00:00:01.000-00:00")))

FAIL in () (form-init18247573092840804319.clj:1)
expected: (= (bean a) (bean Wed))
  actual: (not (= {:day 3, :date 9, :time 1728518401000, :month 9, :seconds 1, :year 124, :class java.util.Date, :timezoneOffset 360, :hours 18, :minutes 0} 
                  {:class clojure.lang.Symbol, :name "Wed", :namespace nil}))
false
smarts.core=>

well thats really weird

you can put a breakpoint on java.util.Date equals method with IntelliJ if you have it around and check from there

{:class clojure.lang.Symbol, :name "Wed", :namespace nil} i think that’s too late in the process. Whatever is going on here seems very strange to me

what is the difference between your (.getTime a) and (.getTime #inst "2024-10-10T00:00:01.000Z")

fwiw, I just created a new empty lein project and the type correctly resolves to Date

inst-test.core=> (type #inst "2024-10-10T00:00:01.000-00:00")
java.util.Date

smarts.core=> (type #inst "2024-10-10T00:00:01.000-00:00")
clojure.lang.Symbol

oh, I missed that

smarts.core=> (type a)
java.util.Date

Given the troubleshooting we have gone through here, I think this succinctly captures the behavior I am seeing.

smarts.core=> (def a #inst "2024")
#'smarts.core/a
smarts.core=> (type a)
java.util.Date
smarts.core=> (type #inst "2024")
clojure.lang.Symbol

can you give the output of evaluating *data-readers* ?

{cheshire/json #'cheshire.core/generate-string, clj-time/date-time #'clj-time.coerce/from-string}

Sounds like neepl middle somewhere is doing something funky

Like call str on a Date object, then calling read on the result, which is producing the symbol Wed

maybe look at ~/.lein/profiles.clj ?

➜  ~ cat ~/.lein/profiles.clj
{:user {:plugins []}}

user=> (str (java.util.Date.))
"Tue Aug 19 12:48:01 PDT 2025"
user=> (read-string (str (java.util.Date.)))
Tue
user=>

Do you have a custom print method defined for java.util.Date?

(get (methods print-method) java.util.Date)
#object[clojure.tools.reader.default_data_readers$fn__4647 0x201fc361 "clojure.tools.reader.default_data_readers$fn__4647@201fc361"]

and similarly for (get (methods print-dup) java.util.Date) (that’s an excellent idea)

(read-string (str #inst "2024-10-10"))
Wed

if you do (require 'clojure.instant :reload) does it fix it?

hoping to restore these

(defmethod print-method java.util.Date
  [^java.util.Date d, ^java.io.Writer w]
  (print-date d w))

(defmethod print-dup java.util.Date
  [^java.util.Date d, ^java.io.Writer w]
  (print-date d w))

=> (get (methods print-dup) java.util.Date)
#object[clojure.tools.reader.default_data_readers$eval13682$fn__13683 0x5278403 "clojure.tools.reader.default_data_readers$eval13682$fn__13683@5278403"]
=> (get (methods print-method) java.util.Date)
#object[clojure.tools.reader.default_data_readers$eval13678$fn__13679 0x6a317923 "clojure.tools.reader.default_data_readers$eval13678$fn__13679@6a317923"]

The reload did not fix it

try #=(java.util.Date.)

(constructs a Date in the reader without using a data reader)

=> #=(java.util.Date.)
#inst "2025-08-19T20:05:11.868-00:00"

and what if you call type on it

=> (type #=(java.util.Date.))
clojure.lang.Symbol

fascinating

clearly, clojure.tools.reader.default_data_readers$eval13682$fn__13683 is not the original

(yeah saw that after)

possible there’s another java util Date class on the classpath?

you can't (easily) shadow that

there are definitely custom printers installed there from clojure.tools.reader

but the repl at least is printing correctly as an inst literal

yes, I'm not sure that's everything (the tools.reader printers just mostly copy the core ones) but I'd try to figure out how that's happening

(deftype Foo []
  Object
  (toString [_] (throw (Exception.))))

(type #=(user.Foo.))