Hi there,

I'm new to Hibernate so allow me to first state how impressed I am with this toolkit. I'm totally blown away with how Hibernate has allowed me to derive an RDBMS schema that was actually better than the non-ORM schema that I had! :-) Kudos to the Hibernate contributors.

One thing that has tripped me up though is around expressing a java.util.Date as a "timestamp with time zone". I'm using a Postgres db and I want to be able to express dates in the UTC form. The default behaviour of Hibernate is to express "timestamp without time zone" (which I believe was done for reasons of portability) and therefore results a java.util.Date being persisted in the local time of the JVM.

Given java.util.Date is intended to represent coordinated universal time (UTC), I would intuitively expect my Date object to be persisted as a UTC value; hence also expecting "timestamp with time zone" to be my default schema mapping.

Is there a method to change the default behaviour of Hibernate with respect to mapping java.util.Date with "timestamp with time zone"? Better still, can I do this via JPA outside of any annotation i.e. in a configuraton file?

Cheers,
-C

AFAIK timestamp is allways saved as a long which represents an exact point in time relative to UTC how you wish to display it is up to you default is JVM's but you change it as you like but the actual long value stays the same allways .

Thanks for your reply. You are correct in that a Date is stored as a long. My question is not so much related to the Java representation of time. What I'm trying to ask is how I can, by default, generate a Date to a "timestamp with time zone" declaration in my schema.

Here's some info on "timestamp with time zone" taken from the Postgres manual:



So, how can I get Hibernate to generate a "timestamp with time zone" by default for whenever is encounters a java.util.Date in my code?

that's what i was trying to say , the value that the timestamp uses is one value trough out the word it's the same long you can't "shift" it according to timezones , that is a presentation level transformation that you have to do each time .
if i presist a new timestamp at the same time in brazil and bulgaria it will hold the same value .
i'm not familiar with Postgres but i know that in mysql you can define the mysql server to run on a diffrent timezone then jvm's and vice versa so that is probably what is ment by those lines , if that is a good idea ? it's up to you i don't think so .

that's what i was trying to say , the value that the timestamp uses is one value trough out the word it's the same long you can't "shift" it according to timezones , that is a presentation level transformation that you have to do each time .
if i presist a new timestamp at the same time in brazil and bulgaria it will hold the same value .
i'm not familiar with Postgres but i know that in mysql you can define the mysql server to run on a diffrent timezone then jvm's and vice versa so that is probably what is ment by those lines , if that is a good idea ? it's up to you i don't think so .

Anyone else?

While I understand what you want to do similar to other posters I don't quite understand why you want to do it. The Date datatype in Java does not carrying timezone information which in turn means any database inserts and updates on a column based on a Date property cannot provide timezone information to the database. It would be different if you want to map a property of type java.util.Calendar to a database column. In that case the use of timestamp with timezone would make sense to me.

Any way, you can control which database type is used for a particular column using the Hibernate mapping file. See http://www.hibernate.org/hib_docs/v3/re ... guide-s1-2.

For example:


Having said that I have no idea if that will work properly.

Because it makes sense to store times in a database in a normalised manner. UTC is the general convention for normalising time when persisted. Having the database take care of this for you is the way to go. That's why we have a "timestamp with time zone" type.



The JVM knows your UTC time. In many instances this is obtained from the OS. The java.util.Date long value can therefore record the number of milliseconds since midnight on 1 Jan 1970 UTC.

Thanks for the info on how to specify the sql type. I do know about this. However what I'm trying to determine is whether one can somehow override the dialect for Postgres and always have Date types mapped to "timestamp with time zone". Apologies if I wasn't specific enough.

Thanks again for the interest.

Cheers,
-C

change your timestamp member setter and add a long that adds/subtracts the "shifting" , the hack if i know why you would like to do that .

Hi Amnon,

I appreciate your replies but I'm not looking for a hack. I'm looking for a general method of being able to specify a mapping of java.util.Date to "timestamp with time zone"; perhaps something to do with overriding the Postgres dialect implementation.

Thanks again and Merry Christmas.

Cheers,
-C

I hope that the forum had a great Christmas.

As a further update I just specified the following JPA annotation for one of my java.util.Date columns:



...and presto, my date was persisted as one would expect i.e. as a UTC value.

This is the functionality that I desire for all of my properties declared as a java.util.Date - by default.

Would subclassing PostgreSQLDialect and replacing:



with:



and then pointing my hibernate.dialect property to my subclass be the correct way to achieve my goal?

Also is there a reason why Oracle and Postgres shouldn't now register timestamps as "timestamp with time zone" always given their adherence to the SQL standard? As mentioned before, java.util.Date represents a UTC time and so does "timestamp with time zone". Is there something I'm missing here or should I submit a change request for Hibernate in this respect?

Thanks for your attention.