Fork me on GitHub
#calva
<
2021-03-15
>
Brian smith14:03:55

Hello, Calva friends! I've been doing Clojure development using Calva on and off for about a year now and have never run across this issue. I'm using clj-time to work with dates/times. When I spin up a REPL by jacking-in, when using the clj-time.local namespace to get local-now, I am getting a date the represents the UTC time zone instead of my local time zone. Is this a REPL problem? A PBCK problem? Thank you for any information!!!! I'm using Remote development to an Unbuntu WSL instance.

seancorfield17:03:29

@brian.smith I’m one of the maintainers of clj-time and I’d recommend not using it, but using the built-in Java Time via interop or one of the Java Time wrappers listed in clj-time’s README.

seancorfield18:03:28

Although it can be confusing, clj-time always works in UTC under the hood, with timezones overlaid. You can see how clj-time.local works in this REPL session:

(! 747)-> clj -Sdeps '{:deps {clj-time/clj-time {:mvn/version "RELEASE"}}}'
Clojure 1.10.3
user=> (require '[clj-time.core :as tc] '[clj-time.local :as tl])
nil
user=> (tc/now)
#clj-time/date-time "2021-03-15T17:56:12.966Z"
user=> (tl/format-local-time *1 :rfc822)
"Mon, 15 Mar 2021 17:56:12 -0700"
user=> (tl/local-now)
#clj-time/date-time "2021-03-15T17:56:24.970Z"
user=> (tl/format-local-time *1 :rfc822)
"Mon, 15 Mar 2021 10:56:24 -0700"
user=> 
Although (tc/now) and (tl/local-now) display identically in the REPL, the former is pure UTC while the latter has the default timezone encoded. You can see that when they are both formatted as local date/time: the former produces a UTC date/time string but the latter produces a local (to me: Pacific time, West Coast USA) date/time string. Even though the REPL displays them identically.

🕐 1
❤️ 1
Brian smith19:03:11

I thought I was going insane for a minute. Thank you for responding. All I've been attempting to do is to find the number of hours difference between two date-times...

seancorfield19:03:10

Date/time stuff is hard and timezones doubly so.

pez14:03:21

Hi @brian.smith, happy to hear from you! Pretty sure it is not to do with the tooling. If you do some regular println testing with lein run (or equivalent), you should be able to confirm wether that is the case or not.

pez14:03:12

I know I get all dizzy trying to figure timezone things out. Having struggled with that a lot in my work project recently. 😃

Brian smith14:03:15

Thanks @pez, I appreciate you responding. I am sure it isn't a problem with the tooling, just my understanding of it.

pez15:03:51

FYI, Calva friends.

ericdallo15:03:39

@brandon.ringe, about https://github.com/BetterThanTomorrow/calva/pull/981 clojure-lsp now has a way to disable all lints (clj-kondo and clojure-lsp new lint) https://clojure-lsp.github.io/clojure-lsp/settings/#diagnostics-linter 🙂

👍 1
bringe16:03:11

Awesome! Thanks for letting me know.

👍 1
seancorfield18:03:28

Although it can be confusing, clj-time always works in UTC under the hood, with timezones overlaid. You can see how clj-time.local works in this REPL session:

(! 747)-> clj -Sdeps '{:deps {clj-time/clj-time {:mvn/version "RELEASE"}}}'
Clojure 1.10.3
user=> (require '[clj-time.core :as tc] '[clj-time.local :as tl])
nil
user=> (tc/now)
#clj-time/date-time "2021-03-15T17:56:12.966Z"
user=> (tl/format-local-time *1 :rfc822)
"Mon, 15 Mar 2021 17:56:12 -0700"
user=> (tl/local-now)
#clj-time/date-time "2021-03-15T17:56:24.970Z"
user=> (tl/format-local-time *1 :rfc822)
"Mon, 15 Mar 2021 10:56:24 -0700"
user=> 
Although (tc/now) and (tl/local-now) display identically in the REPL, the former is pure UTC while the latter has the default timezone encoded. You can see that when they are both formatted as local date/time: the former produces a UTC date/time string but the latter produces a local (to me: Pacific time, West Coast USA) date/time string. Even though the REPL displays them identically.

🕐 1
❤️ 1
sashton21:03:59

I’m exploring calva, and trying out some clojure-lsp features. Calls: Show Call Hierarchy doesn’t work for me. Should it? But when I execute Go to Definition when I am already on the function definition, I do get a popup which shows call references.

bringe01:03:30

I'm not sure if that's implemented in clojure-lsp yet. @UKFSJSM38 could tell us more.

bringe01:03:30

Oh, I see it in the clojure-lsp docs now. I see a fix related to the call hierarchy feature was released in a later version than what Calva uses currently. I'm not sure though if it should be working to some extent right now.

bringe01:03:43

Eric, when I run the call hierarchy command in VS Code, I see in the logs that the textDocument/codeLens and codeLens/resolve requests are made, but that's it. Should something else be happening?

ericdallo01:03:46

We have only support for incoming call hierarchy lsp method and it should work

ericdallo01:03:47

@brandon.ringe it should call textDocument/prepareCallHierarchy and callHierarchy/incoming if I recall correctly

bringe15:03:08

Hmm, okay. I'll create a ticket to track this, since it seems to not work correctly atm.

ericdallo16:03:05

Yes, it works properly on emacs:

👍 1
bringe16:03:50

We don't have any middleware related to that, but I also don't see those requests being made, which is strange. It's possible that feature was added in a newer version of the protocol, but our client uses an older version currently. We'll have to investigate.

ericdallo16:03:51

yes, definitely that was added on latest protocol version, 3.16

bringe16:03:43

Ah, that makes sense then. We'll need to upgrade