3

PostgreSQL 9.3 / postgresql-9.3-1100-jdbc41.jar

I have a table with a column of type timestamp without time zone, this generates my Object with the applicable java.util.Timestamp property.

What I'm seeing, during insert, is jOOQ's binding process converting a java.util.Timestamp into a date with local timezone offset.

eg for a unix timestamp 1421109419 (13 Jan 2015 00:36:59 GMT) the property is set with new Timestamp(1421109419 * 1000).

from the jOOQ logger I see:

2015-01-13 14:14:31,482 DEBUG [http-bio-8002-exec-4] org.jooq.tools.LoggerListener#debug:255 - -> with bind values      : insert into "foo"."bar" ("start_date") values (timestamp '2015-01-13 13:36:59.0') returning "foo"."bar"."id"

2015-01-13 14:14:31,483 TRACE [http-bio-8002-exec-4] org.jooq.impl.DefaultBinding#trace:179 - Binding variable 3       : 2015-01-13 13:36:59.0 (class java.sql.Timestamp)

and sure enough in the record is the value "2015-01-13 13:36:59".

The software is running on a machine in NZDT which explains the +13 offset.

Given the time is being supplied in a TimeZone agnostic container (Timestamp) I would have expected that to be honoured when creating the insert statement.

How can I have jOOQ create timestamps NOT in local time?

Community
  • 1
  • 1
markdsievers
  • 7,151
  • 11
  • 51
  • 83
  • So your domain model has `Timestamp` fields directly defined? So it's not going through a jOOQ Converter http://www.jooq.org/doc/3.5/manual/sql-execution/fetching/data-type-conversion/ ? – Alex Jan 13 '15 at 04:41
  • Correct - `java.util.Timestamp` is what is generated by jOOQ and what is being populated by me. No intermediate converters. – markdsievers Jan 13 '15 at 19:16
  • I'm seeing a few references to the PostgreSQL driver being the cause of this. If that is the case, is there any method in jOOQ I can leverage to push through timestamps as a function of an epoch value eg `TIMESTAMP WITHOUT TIME ZONE 'epoch' + 1421109419 * INTERVAL '1 second'` ? – markdsievers Jan 13 '15 at 19:50
  • I'm not sure if this info applies to your case, but in mine I was trying to use `between( date1, date2 )`; no matter what timezone the two date objects were in, the query always turned them into local time. I was able to get around it with `between( date1.toString(), date2.toString() )`, with the two date objects being in UTC. – Gary Feb 24 '21 at 15:27

2 Answers2

6

Unfortunately you have a few things working against you:

  1. The PostgreSQL JDBC driver sets the timezone to your JVM timezone in the Postgres session. So even if your Database Server is running in UTC a TIMESTAMP field will be inserted using the time zone of your JVM. When you insert or query data the database server will always use the JVM time zone.
  2. You are using TIMESTAMP instead of TIMESTAMPTZ. The description of these types do not reflect their actually usage. TIMESTAMPTZ actually means time zone agnostic. Whatever value you insert it will be adjusted to UTC using the session timezone.

Because of these two issues, if you have two different JVMs -- one using Los Angeles time and the other using New York time -- whenever you write a TIMESTAMP with one JVM it will be a different "UTC time" in the other JVM. TIMESTAMP takes the adjusted value and just uses it as given. If you change your TIMESTAMP columns to be TIMESTAMPTZ then the same time in both JVMs will always be the same UTC time.

If you look at the Postgres JDBC Driver's ConnectionFactoryImpl#openConnectionImp you can see where it sets your local JVM's time zone as the time zone for the database server's session zone.

So the only sane way to deal with this is to only ever use TIMESTAMPTZ instead of TIMESTAMP. Here's some more information on this:

PostgreSQL/JDBC and TIMESTAMP vs. TIMESTAMPTZ

http://justatheory.com/computers/databases/postgresql/use-timestamptz.html

Community
  • 1
  • 1
robert_difalco
  • 4,821
  • 4
  • 36
  • 58
0

The following (very nasty) code works for me:

eventsRecord.setCreatedOn(new Timestamp(System.currentTimeMillis() 
  - TimeZone.getDefault().getOffset(new Date().getTime())));

Alas jOOQ simply uses the local timezone when saving into PostgreSQL "timestamp without timezone" or MySQL "datetime" fields. The source code evidence for this travesty is here, it does not specify the timezone nor have any facility for the user to override this functionality and specify a timezone. This renders usage of this very basic datatype from jOOQ completely useless, with a multitude of clients all with different timezones writing data to the same field without recording their timezone nor normalizing the data to UTC.

JDBC provides an extra three-argument setTimestamp where the user can specify what timezone is desired (UTC is basically the only value that makes sense). However jOOQ "abstracts" away from JDBC and does not offer this facility.

Adrian Smith
  • 17,236
  • 11
  • 71
  • 93