Also bear in mind that 'turning off' date localization for an attribute only affects how it is displayed in the client browser, not how it is stored in the database.
The date-time will always be stored in the database as UTC. If you have localization turned on, the display of this date will be adjusted to take account of your timezone. If localization is turned off, the date displayed will be just UTC time. One further complication is to do with daylight savings...
If you look into the future (or past) at a date that was saved when daylight savings is different from how it is now (like now is summer time, look at a date later in the year after the clocks go back in the autumn), you will see one hour more(or less) offset than you expect. That is because the effect of daylight savings is to move you to a different timezone (you have a different UTC offset) for part of the year.
You can really give yourself a headache thinking to much about these things. It's a bit like relativity - how the date looks depends on where you are looking at it from. But at the database level it is always simple - always stored in UTC
Update: I have checked on a server located in California (PST) viewing the dates from both the UK (GMT, currently UTC + 1) and from the server itself (PST, currently UTC - 7). Here is the result:
As you will see, both the system createdDate and a custom create date are exactly the same in the database. The system createdDate is ALWAYS displayed in UTC. The create date localized field is displayed adjusted for the correct client timezone.
Could it be that when importing that date from another database, you're treating the representation of the date as a localized date in your java action when it should be UTC?
For more insight in Dates and times in Java, read http://www.odi.ch/prog/design/datetime.php
I just checked the java action and the date fetched when using toString() is still correct. So it must be while committing.
I suspect your issues with createdDate and changedDate are explained in this thread.