First Lesson: Fear the DST!
The simplest implementation which you will find in many libraries just uses the default time zone everywhere. This error is even present in Joda Time's own Hibernate integration project.
This breaks on the transition to DST. By advancing the clock one our, we end up with times that do not exist. For instance new LocalDateTime(2014, 3, 30, 2,0).toDateTime() will crash in CEST, because the clock advances from 01:59 directly to 03:00.
Second Lesson: Calendar.getInstance() is slow!
So to work around this, we need to specify a time zone that has no DST. Our best candidate is of course UTC. But when we use UTC for conversion to the Timestamp, we also need to tell the JDBC driver to use UTC. This can be done by an additional Calendar argument.
At first I used a new Calendar instance each time this method was called, which resulted in pretty bad performance.
Third Lesson: Don't trust vague JavaDoc!
So I refactored towards a constant Calendar. I knew that Calendars are not thread safe. But the JavaDoc says that it is only used for specifying the timezone and locale to use. So this implies that the Calendar will not be written to and can thus be shared among threads.
Well, it turns out that the Oracle SQL driver does use this Calendar for calculations, so you end up with several threads writing the one instance, resulting in garbage data.
Finally - working and fast
So finally I replaced the shared Calendar with clones. That's much faster than obtaining a new instance, but safe at the same time. I can only recommend you do the same for your converters.
Special thanks go to Sun for getting us into this mess in the first place through Java's horrible Date/TimeStamp/Calendar API.