2013-08-19T08:00:00.000 in UTC == 2013, August, 19, 10:00:00 CEST no? So the lack of timezone information causes it to think that the date is in UTC. Turned into a javascript date object it adds in timezone information and shifts it up 2 hours?
As for a workaround, in the client side you could get the date as UTC since you seem to be sending it in UTC format:
var date = new Date(dateField);
var date_utc = new Date(date.getUTCFullYear(),date.getUTCMonth(),date.getUTCDate(), date.getUTCHours(),date.getUTCMinutes(),date.getUTCSeconds());
-----Original Message-----
From: Witold Szczerba [mailto:pljosh.mail_at_gmail.com]
Sent: Monday, August 19, 2013 6:07 PM
To: users_at_glassfish.java.net
Subject: JAX-RS: date fields are incorrectly marshalled
Hi there,
Today I have found that, by default, Glassfish 4 JAX-RS handles POJO to JSON conversion very unfortunately, here is an example result:
2013-08-19T08:00:00.000 (not timezone means UTC) The date above was created like this:
Calendar c = new GregorianCalendar();
//calendar uses my current, CEST, timezone c.set(YEAR, 2013); c.set(MONTH, AUGUST); c.set(DAY, 19); c.set(HOUR, 8); c.set(MINUTE, 0); c.set(MILLISECOND, 0); return c.getTime();
When I print this, I get:
2013, August 19, 08:00:00 CEST
which is equivalent of:
2013, August, 19, 06:00:00 UTC
So, in CEST we have 8am, while it is 6am UTC.
Now, Glassfish, using MOXy is generating:
2013-08-19T08:00:00.000
and in JavaScript
var date = new Date(dateField);
produces:
2013, August, 19, 10:00:00 CEST.
So, instead of 8am we have 10am.
I think this is a major bug, it causes all the applications, by default, to produce invalid dates.
I have asked my colleague from different project, they use GF4 as well, he said they do not have that issue. When we double checked, we discovered a major bug in that application, they just were not aware of it.
Can anyone else confirm this is a bug? IS there any workaround? Should it be reported to MOXy or Glassfish? I cannot tell where the problem is.
Regards,
Witold Szczerba