This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-25
Channels
- # aleph (1)
- # beginners (72)
- # boot (3)
- # cider (28)
- # cljs-dev (193)
- # cljsrn (11)
- # clojure (73)
- # clojure-brasil (3)
- # clojure-gamedev (2)
- # clojure-russia (6)
- # clojure-spec (30)
- # clojure-uk (26)
- # clojured (1)
- # clojurescript (32)
- # code-reviews (9)
- # core-async (4)
- # datascript (5)
- # datomic (9)
- # dirac (38)
- # fulcro (23)
- # garden (11)
- # leiningen (1)
- # luminus (11)
- # lumo (6)
- # off-topic (17)
- # quil (2)
- # re-frame (2)
- # reagent (3)
- # ring (3)
- # shadow-cljs (12)
- # spacemacs (4)
- # sql (2)
- # unrepl (85)
- # vim (3)
A colleague of mine noticed that dates on our MSSQL server are interpreted relative to the timezone of the client:
(do
(TimeZone/setDefault (TimeZone/getTimeZone "Europe/Copenhagen"))
(jdbc/query conn "select getdate() as now"))
;; => ({:now #inst"2018-02-25T20:56:12.227000000-00:00"})
(do
(TimeZone/setDefault (TimeZone/getTimeZone "UTC"))
(jdbc/query conn "select getdate() as now"))
;; => ({:now #inst"2018-02-25T21:56:29.427000000-00:00"})
We can mitigate this by setting the timezone of the client to that of the server:
(TimeZone/setDefault (TimeZone/getTimeZone "<server timezone>"))
.
Is there any way of making this approach thread safe?@grav Timezones are very problematic with databases -- the only really sane option is to have all your servers and all your software running in UTC and translate to/from the end user TZ at the edges.