On 5-10-2018 15:40, Vlad Mihalcea wrote:
> Hi,
>
> My question was more about LocalTime, which is much more straightforward to
> address than LocalDateTime in the context of time zones.
>
> For DateTime types which support timezones, I'll have to study to see what
> other non-breaking
On Fri, 5 Oct 2018 at 14:40, Vlad Mihalcea wrote:
>
> Hi,
>
> My question was more about LocalTime, which is much more straightforward to
> address than LocalDateTime in the context of time zones.
Ok so specifically discussing LocalTime.
If you *really must* store a LocalTime as an absolute
Hi,
My question was more about LocalTime, which is much more straightforward to
address than LocalDateTime in the context of time zones.
For DateTime types which support timezones, I'll have to study to see what
other non-breaking alternatives we may have.
Vlad
On Fri, Oct 5, 2018 at 2:28 PM
Ah good, its time for this yearly discussion :D
The problem is as Vlad points out. We are kind of forced to do *something*
wrt timezone to often times counteract what the JDBC driver will do. As I
have always contended, imo that saving a date into the database with any
kind of timzone (other
On Fri, 5 Oct 2018 at 10:28, Vlad Mihalcea wrote:
>
> Hi
>
> IMO no timezone conversion whatsoever should be applied when
> > persisting LocalDateTime as it doesn't contain any TZ information.
>
>
> That's not very easy to do since either the JDBC Driver or the database
> engine might to the
Hi
IMO no timezone conversion whatsoever should be applied when
> persisting LocalDateTime as it doesn't contain any TZ information.
That's not very easy to do since either the JDBC Driver or the database
engine might to the timezone conversion based on the underlying setting.
In fact I'd even
> In fact I'd even recommend to use a string-based column type to store
> LDT, as it avoids these kinds of issues altogether.
Or just, you know, "timestamp without timezone". Where possible.
More to the point, I agree with Vlad's proposition, and I also think ORM
should avoid messing with
IMO no timezone conversion whatsoever should be applied when
persisting LocalDateTime as it doesn't contain any TZ information.
If the target column type requires a TZ, it should be set to UTC,
storing the given value without any shift. I.e. the LDT value
2007-12-03T10:15:30 should be stored as
