(I am in the UTC+2 timezone, which I assume is the 2 hour difference).
I'm busy writing a JSON RESTful API that's part of a Grails application (2.0.3 on this project in particular, but this problem occurs in other versions). I use Jackson for Serialization and Deserialization of Json, and the JsonService's configuration looks like this: http://pastebin.com/JacytMuF
So multiple Domain objects have values collated and represented in a single DTO (in this case it's a simple map), and these are just passed to the JsonService to convert to Json, which is returned (to a request). All of the fields are serialized correctly, with the exception of two of the (several) Dates, which are off by 2 hours. I can for example run:
db_dev=# select next_billing_date from account where code = 'CATS001';
next_billing_date
---------------------
2013-06-20 00:00:00
and this is verified to be correct (within memory) by this little action
def checkTimezone() {
Account acc = Account.findByCode("CATS001")
log.error(acc.nextBillingDate)
}
which returns
ERROR mash.TestController - 2013-06-20 00:00:00.0
as expected. Furthermore, I can check that nothing tampers with the in-memory value by doing, within the RestAccountController:
def show() {
...
def ans = [ code: ac.code, nextBillingDate: ac.nextBillingDate ]
log.error("CATTTTSSSSSSSSSSSSSS::::: ${ac.nextBillingDate}")
[ans: ans]
}
(returning)
ERROR mash.RestAccountController - CATTTTSSSSSSSSSSSSSS::::: 2013-06-20 00:00:00.0
Yet when I hit the relevant endpoint, I get:
nextBillingDate": "2013-06-19T22:00:00.000+0000"
Which is off by 2 hours. The nextBillingDate property is a normal Java Date object, the underlying database is psql:
next_billing_date | timestamp without time zone | not null | plain |
And hence I am a bit lost for ideas on why it's randomly deducting 2 hours. I can see why 2 hours is the magic number (timezone differences), but I cannot explain why it's offsetting the Date on some objects (or indeed only on some subset of the Date objects).