Hi Witold,
*EclipseLink MOXy <
http://www.eclipse.org/eclipselink/moxy.php>* represents dateTime information as ISO 8601. In this format when a time zone is not present the time is considered to be in the local time zone and not UTC (of course the suffix `z` can be used to indicate UTC).
*
http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
Of course the lack of a time zone indicator and it always being interpreted in the local timezone makes it difficult to process. My proposal is for MOXy to include the time zone when marshalling /java.util.Date/ (see existing bug below):
*
http://bugs.eclipse.org/413979
*Work Around*
The following workaround can be used with the existing code.
*SessionEventListener (MySessionEventListener)*
You can use a /SessionEventListener/ to tell MOXy to include a time zone qualifier.
import org.eclipse.persistence.internal.oxm.XMLConversionManager;
import org.eclipse.persistence.sessions.SessionEvent;
import org.eclipse.persistence.sessions.SessionEventAdapter;
public class MySessionEventListener extends SessionEventAdapter {
@Override
public void postLogin(SessionEvent event) {
XMLConversionManager xcm = (XMLConversionManager) event.getSession().getDatasourcePlatform().getConversionManager();
xcm.setTimeZoneQualified(true);
super.preLogin(event);
}
}
*Leveraging SessionEventListener*
Below is a code example of specifying the /SessionEventListener/ when creating the /JAXBContext/. To leverage this in a JAX-RS environment you will need to use a /ContextResolver/ (see:
http://blog.bdoughan.com/2011/04/moxys-xml-metadata-in-jax-rs-service.html).
import java.io.File;
import java.util.*;
import javax.xml.bind.*;
import org.eclipse.persistence.jaxb.JAXBContextFactory;
import org.eclipse.persistence.jaxb.JAXBContextProperties;
public class DateDemo {
public static void main(String[] args) throws Exception {
Map<String, Object> properties = new HashMap<String, Object>(1);
properties.put(JAXBContextProperties.SESSION_EVENT_LISTENER, new MySessionEventListener());
JAXBContext moxy = JAXBContextFactory.createContext(new Class[] {DateRoot.class}, properties);
}
}
-Blaise
Blaise Doughan
Team Lead, EclipseLink MOXy
>> Begin forwarded message:
>>
>>> *From: *Witold Szczerba <pljosh.mail_at_gmail.com <mailto:pljosh.mail_at_gmail.com>>
>>> *Subject: **JAX-RS: date fields are incorrectly marshalled*
>>> *Date: *August 19, 2013 3:06:44 PM PDT
>>> *To: *users_at_glassfish.java.net <mailto:users_at_glassfish.java.net>
>>> *Reply-To: *users_at_glassfish.java.net <mailto:users_at_glassfish.java.net>
>>>
>>> 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