Earlier this month I submitted some patches for this exact issue into Joda Time, you can view the details here:
https://sourceforge.net/mailarchive/forum.php?thread_name=950497.37564.qm%40web27108.mail.ukl.yahoo.com&forum_name=joda-interest The problem is that the Joda Time types do not pass a timezone inside nullSafeSet to the JDBC API – this behaviour is shared with Hibernate’s builtin support for Time, Date and Timestamp. I’ve put some detailed discussion on my blog which describes this in more detail – have a look at http://blog.jadira.co.uk/blog/2010/5/1/javasqldate-types-and-the-offsetting-problem.html I found this problem whilst unit testing some user types I wrote for use with JSR 310, as these types took account of the offsetting, in the event it has proven quite straightforward to add Joda Time to these types as well, so you might want to take a look and see if these solve your problem. The Sourceforge project page is here: http://usertype.sourceforge.net/. Note that these classes need Java 5 (the classes in Joda Contrib work with Java 1.4) Stephen it would be great if you could add this to the list of related projects? Thanks Chris From: Sean Mitchell [mailto:s...@mitchwood.com] Sent: 06 May 2010 19:02 To: Discussion of the Joda project Subject: Re: [Joda-interest] Dealing with separate time and timezone DBfields - Email found in subject On Thu, May 6, 2010 at 11:28 AM, Adam Gordon <adam.n.gor...@gmail.com> wrote: Unfortunately, we need the time zone - either implicitly or explicitly - as it's required in a bunch of different areas. If you need to know what the timezone is, then perhaps your subcontractor got it right. I'm guessing that you need to format the output of these records according to the timezone they were entered in? If so, you'll need to have that Timezone in your POJO. We dug deeper into the PersistentDateTimeTZ class and found that there's a method nullSafeSet and it appears that even though the data type in postgres is timestamp without time zone, you cannot get a timestamp out of the database WITHOUT an implicit time zone value, in this case our local time, and you have to do some really nasty/gross Java in order to convert it. Lesson learned is do not store timestamps in the database without a time zone. We will most likely have to do a data migration to fix this and not have to use nasty code. Typically databases do not store a timestamp with the timezone, they convert it to UTC. This is essentially the same thing that Java does. It's actually important that you *store* timestamps this way if you want to support timezones properly, because timezones are really just formatting details. The instant in time is what is important, whether I call it 2010-05-05 12:00 or my buddy in London England calls in 2010-05-05 17:00. It's the same moment in time. Joda time saved my butt recently due to the lame JDK implementations of SimpleDateFormat, but I'm not sure that I would use them beyond getting sane Date instances from time and possibly the other why around. IMO Sun was right to split out the Calendar and Date classes to make clear the separation between a moment in time, and what people in different parts of the planet call that moment. Cheers, Sean
------------------------------------------------------------------------------
_______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
