Clojurians Log v2

It depends on the jdbc driver you use

I think newer MySQL drivers default to java.time

Snowflake

Check out next.jdbc.date-time/read-as-instant and other functions in that ns.

(Assuming you use next.jdbc)

But but time zone issues are not likely to change because you change the type mapping

If you are storing in a column that doesn't include timezone data, and your database clients are not configured for the same tz as the database you will have all kinds of issues

The column has offset in the timestamp

Then I would be very surprised if it wasn't being applied correctly with Dates (although I guess I really don't have experience with snowflake)

And why is it read as java.sql.Date then and not java.sql.Timestamp?

Are you just seeing #insts printed and assuming they are Dates?

I'm pretty sure it's a Date

So with that driver... how do you even read a timestamp then?

Ah, sorry, I missed that it was java.sql.Date, not java.util.Date

So a SQL Date type, not a timestamp

yeah, I can also get it back as a net.snowflake.client.jdbc.SnowflakeTimestampWithTimezone, which has methods to convert it to java.time types, including zone, so I think I'll work with that

I think it is likely that the "standard" SQL Date type doesn't support timezone information, so it could be getting dropped / mangled in someway despite it being stored in snowflake when shoving it into java.sql.Date

okay, so I'm at a time offset, if I take the snowflake timestamp with timezone and call .toLocalDateTime it adds the offset before conversion. If I call .toZonedDateTime then on ZonedDateTime/.toLocalDateTime the offset is not applied Why is the offset applied when converting from classes inheriting from Date and not from java.time?

It likely has to do with the timezone your jvm is configured for

yeah, this solved it

(java.util.TimeZone/setDefault (java.util.TimeZone/getTimeZone "UTC"))

If I recall java util Date implicitly timezoned to whatever the jvm is set for