Respect the offset of OffsetTime when persisting/loading data

I have fixed the bug here. We now no longer just throw away the offset when persisting an OffsetTime.

I guess the first option is the one we would have to go with, since converting to UTC would mean that we would be incompatible with our own data.

So my suggestion would be, either:

Change line 85 of OffsetTimeJavaType to:

return (X) Time.valueOf( offsetTime.withOffsetSameInstant( OffsetDateTime.now().getOffset() ).toLocalTime() );

Or, change line 85 to:

return (X) Time.valueOf( offsetTime.withOffsetSameInstant( ZoneOffset.UTC ).toLocalTime() );

And line 143 to:

return ( (Time) value ).toLocalTime().atOffset( ZoneOffset.UTC );

WDYT?

So I note that the linked stack overflow question is using a timetz column in Postgres (which doesn’t really store the offset, it just converts to UTC), and a commenter replies with a link to the Postgres wiki where they tell you to “Never” use timetz.

So I don’t think we should do anything to encourage this usage.

So what’s a sensible thing to do with an OffsetTime? Currently, eyeballing the code, it looks like we just throw away the offset and send the LocalTime part to the database. This is pretty bad: it doesn’t even result in consistent interpretations of OffsetTimes in the current JVM! But this is simply a bug in OffsetTimeJavaType I would say.

Well, I guess the only things that could possibly be reasonable would be:

1. convert it to UTC before sending it to the database, or

2. convert it to the JVM offset before sending it to the database.

Neither are great, but UTC looks better to me.

Alternatively, we could simply deprecate support for persisting OffsetTimes, and save everyone a lot of head-scratching.

See discussion on the PR: