This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-26
Channels
- # aleph (2)
- # aws-lambda (18)
- # beginners (81)
- # boot (3)
- # cider (25)
- # cljs-dev (274)
- # cljsjs (10)
- # clojars (25)
- # clojure (65)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-dev (33)
- # clojure-dusseldorf (6)
- # clojure-gamedev (3)
- # clojure-italy (17)
- # clojure-poland (3)
- # clojure-russia (7)
- # clojure-spec (48)
- # clojure-uk (45)
- # clojured (1)
- # clojurescript (26)
- # core-logic (2)
- # data-science (4)
- # datascript (6)
- # datomic (58)
- # defnpodcast (2)
- # docker (1)
- # duct (14)
- # figwheel (2)
- # fulcro (130)
- # graphql (3)
- # leiningen (1)
- # liberator (15)
- # luminus (5)
- # nrepl (1)
- # numerical-computing (1)
- # off-topic (45)
- # onyx (15)
- # re-frame (9)
- # reagent (3)
- # ring (1)
- # shadow-cljs (91)
- # spacemacs (8)
- # sql (23)
- # unrepl (38)
- # videos (2)
- # vim (12)
@seancorfield Yes, UTC would be preferable. It’s not a possibility to change this, however, so I’m looking for the next-best thing 🙂
@grav That's unfortunate. I don't think there's a thread safe way to deal with that. Is setting the client app TZ to match the DB server just once at startup an option?
@seancorfield That’s what we’re doing now, but there’s the risk that something else (a library, someone else’s code) messes with the timezone. Not that it’s very likely to happen.
passing "-Duser.timezone=UTC" (or whatever) at jvm startup is maybe a better idea then calling TimeZone/setDefaultTimeZone
yeah, you avoid having different behaviors before and after calling TimeZone/setDefault
Just to be sure - calling TimeZone/setDefault anywhere in the code will override the jvm startup option, right?
Cool, just wanted to make sure I understood it correct. But I agree that passing it as an option is a good alternative to doing it in code.
a library could create a thread that calls it at some arbitrary point that happens between you calling it and calling jdbc/query
so half the dates in the results would be constructed with one timezone, half with another
That’s probably impossible to do anything about then, I guess, apart from using another driver. I looked briefly at a jtds driver, but I did not have success connecting to the server with it
yeah, anything that takes whatever the date representation in the data base is (a pile of bytes) and presents it to you has some kind of date object is going to have the issue
Well we have looked at using DateTimeOffset, which contains time zone-info, and which you can get by extending the query with "AT TIME ZONE 'Central European Time'"
or something.
This gives us a microsoft.sql.DateTimeOffset
which we’d then have to convert into a #inst
.
I guess the conversion could be done by extending a protocol, but we’d still have to put "AT TIME ZONE ..."
after each and every datefield in the queries.