Fork me on GitHub
#sql
<
2018-12-10
>
nickmbailey22:12:49

so apparently the java.sql spec says when you insert dates they automatically get converted to the default time zone of the jvm

nickmbailey22:12:53

which seems insane to me

nickmbailey22:12:14

is this just something people know to work around and set the default timezone of the jvm to utc on startup?

nickmbailey22:12:21

or am i missing something

seancorfield22:12:45

Yup, it is both insane and something that people know to work around 🙂 The best practice is to set the TZ of every single server you use to UTC, set the database to UTC as well (if needed), and set the JVM TZ to UTC (again, if needed). Then convert to/from local time just at the edges, for display / input purposes only.

nickmbailey22:12:20

sigh well now i know i guess

nickmbailey22:12:43

i mean we were being good and using utc everywhere

nickmbailey22:12:57

but my jvm was running with the timezone of my laptop of course

nickmbailey22:12:52

just so crazy to see a value change between when java.jdbc/to-sql-value creates it and postgres gets it

seancorfield22:12:25

My solution to that is to run a REPL on the production server and connect to it from my dev box -- so I'm working in UTC, even from my own machine 🙂

seancorfield22:12:39

(just to run SQL stuff)

nickmbailey22:12:53

i mean i'm just gonna add a call to TimeZone/setDefault to the service skeleton for all our stuff

seancorfield22:12:29

But, yeah, this bites me sometimes when I'm running Percona in Docker on my desktop and my JVM running the tests is on Pacific time. I try to not insert JVM-created dates, as much as possible and use SQL's NOW() and DATE_ADD()/`DATE_SUB()` where I can.

nickmbailey22:12:49

yeah good advice

nickmbailey22:12:56

i was just trying to insert a birth date haha

nickmbailey22:12:41

anyway, thanks for confirming its the world that is crazy and not me

seancorfield22:12:21

I can neither confirm nor deny your sanity. I can, however, confirm the world is crazy.