Fork me on GitHub
#sql
<
2018-02-26
>
grav06:02:18

@seancorfield Yes, UTC would be preferable. It’s not a possibility to change this, however, so I’m looking for the next-best thing 🙂

seancorfield16:02:29

@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?

grav17:02:52

@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.

hiredman18:02:21

passing "-Duser.timezone=UTC" (or whatever) at jvm startup is maybe a better idea then calling TimeZone/setDefaultTimeZone

grav19:02:18

@hiredman Because it’s set before any code is executed?

hiredman19:02:26

yeah, you avoid having different behaviors before and after calling TimeZone/setDefault

grav19:02:26

Just to be sure - calling TimeZone/setDefault anywhere in the code will override the jvm startup option, right?

hiredman19:02:09

sure, but there is nothing you can do about that

grav19:02:52

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.

hiredman19:02:00

a library could create a thread that calls it at some arbitrary point that happens between you calling it and calling jdbc/query

hiredman19:02:30

the library thread could even call it in the middle of realizing the results

hiredman19:02:07

so half the dates in the results would be constructed with one timezone, half with another

grav19:02:13

Hehe, yes. It’s unfortunate that clojure.java.jdbc relies on global state like that

hiredman19:02:24

it is the jdbc driver

grav19:02:38

Ah ok …

grav19:02:29

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

grav19:02:47

And it probably has the same problem

hiredman19:02:36

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

grav19:02:43

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.

grav19:02:16

This gives us a microsoft.sql.DateTimeOffset which we’d then have to convert into a #inst.

grav19:02:00

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.

hiredman19:02:46

I don't know which is worse, running your app not in utc, or running the app in utc and translating back and forth to the database

grav19:02:32

No … both are not optimal.