Correct, Cayenne follows the first approach. You can create a custom
ExtendedType (or types) for the appropriate value types to alter this behavior.
I guess I am with John in that the most portable approach is to keep your JVM
on UTC. Wonder if introducing a TZ offset as a potential future Cayen
Am Sat, 25 Mar 2017 17:57:40 +
schrieb John Huss :
> The jvm time zone should always be set to UTC. It will avoid problems
> and has no real downsides.
true, but not always in the hands of the software developer. It may
lead to conflicts when one library expects UTC while another the local
TZ
The jvm time zone should always be set to UTC. It will avoid problems and
has no real downsides.
On Sat, Mar 25, 2017 at 11:57 AM Dirk Lattermann
wrote:
> Derby (and H2), for example, store TIMESTAMP values not as a time offset
> from some epoch, but as a local datetime value, without time zone
>
Derby (and H2), for example, store TIMESTAMP values not as a time offset
from some epoch, but as a local datetime value, without time zone
information.
There are two possibilities to map that by JDBC:
1. to java.util.Date, java.sql.Date, java.sql.Timestamp: the JVM's
system time zone is used to co
