This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-06
Channels
- # announcements (1)
- # beginners (147)
- # boot (9)
- # calva (28)
- # cider (3)
- # circleci (18)
- # cljdoc (54)
- # cljs-dev (55)
- # cljsrn (22)
- # clojure (179)
- # clojure-canada (9)
- # clojure-dev (74)
- # clojure-europe (1)
- # clojure-italy (15)
- # clojure-nl (7)
- # clojure-spec (30)
- # clojure-uk (55)
- # clojurescript (65)
- # core-async (15)
- # cursive (12)
- # datomic (16)
- # events (4)
- # fulcro (25)
- # graalvm (3)
- # joker (2)
- # kaocha (15)
- # keechma (94)
- # off-topic (12)
- # qlkit (2)
- # re-frame (15)
- # reagent (11)
- # reitit (29)
- # remote-jobs (15)
- # rewrite-clj (16)
- # shadow-cljs (73)
- # spacemacs (144)
- # sql (3)
- # tools-deps (11)
- # unrepl (19)
- # vim (35)
Btw. on the general advice to "always use UTC" - it's not always that easy: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
Why I recommend always using TIMESTAMPTZ
over TIMESTAMP
is that I think this is dangerous:
INSERT INTO dummy.ts_test(ts, ts_tz)
VALUES ('2019-06-06T11:48:51.133+08', '2019-06-06T11:48:51.133+08');
SELECT * FROM dummy.ts_test;
ts | ts_tz
-------------------------+----------------------------
2019-06-06 11:48:51.133 | 2019-06-06 03:48:51.133+00
(1 row)
Postgres happily accepts value 2019-06-06T11:48:51.133+08
for TIMESTAMP
field and just ignores the +08
which could lead to interesting results.