Information is losing during saving PersistentDateTimeAndZoneWithOffset

[davseitsev]

In line 90 we are losing information in expression myValue.toLocalDateTime(); Method toLocalDateTime() cause adding/subtututing local TZ offset from milliseconds.

As a result we save wrong date in first column. This can cause different troubles. For example, if mutiple application connect to the same database but they have different TZ settings, each application will get different date.

The offset is difference between local time zone offset and database time zone offset (by default is UTC).

The same issue was in PersistentDateTime class in 3.1.0.CR1 and it has been fixed already.

Code to analyze:

DateTime now = DateTime.now();

System.out.println(now.toLocalDateTime().toDateTime().getMillis() - now.withZone(DateTimeZone.UTC).toLocalDateTime().toDateTime().getMillis());

Your local time zone shouldn't be UTC.

[chrisphe]

Not sure where this refers to. Please can you supply more information - or whether this exists in the current codebase.

[davseitsev]

Oh, guys. It was more than half year ago! I don't remember the details. See PersistentDateTimeAndZoneWithOffset:90 there must be the trouble. As I remember, timezone offset (in millis) is subtracted from timestamp (milliseconds) when DateTime is saved. And when DateTime is read, timezone offset is added. But this doesn't happen with LocalDateTime. So, you cannot compare LocalDateTime and DateTime in SQL query, you cannot write date as DateTime and read it as a LocalDateTime etc.

[chrisphe]

The next build will remove databaseZone in favour of using the Hibernate parameter. You'll still be able to set Java Zone in some cases.

[chrisphe]

I've reinstated databaseZone, but it now delegates to Hibernate to handle (by proxying the resolution of the TimeZone from the session). This means it overrides the Hibernate property, but it also means the database zone must be specified using JDK TimeZone format in all cases.