zone-id isn't used, so I'd guess it's a time zone difference

what does (int (/ (.getTime my-date) 1000)) evaluate to?

more, importantly, I suppose, is what does (.getTime my-date) evaluate to...

@U014Z9N3UTS As @U013JFLRFS8 says, it's a timezone issue. I'm West Coast:

user=> (import '(java.text SimpleDateFormat))
java.text.SimpleDateFormat
user=> (new SimpleDateFormat "yyyyMMdd HH:mm")
#object[java.text.SimpleDateFormat 0x5bca7664 "[email protected]"]
user=> (.parse *1 "19700101 00:00")
#inst "1970-01-01T08:00:00.000-00:00"
user=> 

Note the T08 for the hours.

user=> (.getTime *1)
28800000
user=> (int (/ *1 1000))
28800

(18000 is 5 hours, 28800 is 8 hours)

If you look in the test, you can see that it specifies the UTC timezone. The Unix epoch is defined in UTC, which is why I'm having a hard time finding the problem.

I found the problem. I forgot to use the zone-id input in my function. Thanks for reading everybody!

Also use java 8's java.util.time.* https://www.baeldung.com/migrating-to-java-8-date-time-api

(import '(java.time.format DateTimeFormatter)
          '(java.time LocalDateTime ZoneOffset))
  (def formatter (DateTimeFormatter/ofPattern "yyyyMMdd HH:mm"))
  (-> (LocalDateTime/parse "19700101 00:00" formatter)
    (.toInstant (ZoneOffset/UTC))
    (.toEpochMilli)
    (/ 1000))

"I found the problem. I forgot to use the zone-id input in my function. Thanks for reading everybody!" -- @U013JFLRFS8 gets the debugging prize!

@U04V70XH6 damn right 😂

I've been engaged with clojure for over a decade and have no idea what auto-quoting would be, definitely have not heard it mentioned

In general, you want the thread to be non-daemon. Taking selected bits from the Thread javadoc: > ... The Java Virtual Machine continues to execute threads until either of the following occurs: > ... > • All threads that are not daemon threads have died... There are several ways to accomplish this, from using the Thread constructor via raw interop to using Clojure functions that start/use non-daemon threads (future or pmap, for example).

Thanks a lot @U013JFLRFS8

1. what is the value of the accumulator for your reduce function on the first call? 2. what is the value of the accumulator on the second call?

i think 0+ 1 and then 1+0 ... not null 😅

Is there a way to check?

What is the value of (:result 1)?

it's (:result {:result 1}) non?

under the impression each map in the vector becomes an input

I am missing something fundamental 😅

there's fancier ways of doing it, but have you tried sprinkling in some print statements?

internal screaming at a 2.8-3.1 / 10

What is bad about

(reduce 
  #(+ (:result %1) (:result %2))   
  0 
  [{:result 0} 
   {:result 1} 
   {:result 2}])

have you tried printing the arguments to your reducing function?

what does (:result 0) evaluate to?

The prn is helpful...

(reduce 
#(prn %1 %2) 
0 
[{:result 0} 
 {:result 1} 
 {:result 2}])

0 {:result 0}
nil {:result 1}
nil {:result 2}
nil

(reduce (fn [r1 r2] (+ (if (keyword? r1) (:result r1) r1) (:result r2))) 0 rft)

if it's a keyword, grab the val under the key, otherwise just grab the presumed-int

thanks 😄 it was making me cranky

pretty sure the keyword? branch doesn't do anything

(reduce (fn [r1 r2]
          (+ r1 (:result r2)))
        0
        rft)

which I would improve by using slightly better names:

(reduce (fn [cnt m]
          (+ cnt (:result m)))
        0
        rft)

As food for thought, you could also write it more directly with transduce:

(transduce (map :result) + rft)

ty

Thank you, that is a lot clearer now, that one of the arguments is the accumulator. I was not appreciating that.

The 2 arg arity of reduce is evil, try to always provide init value if you can