Skip to main content

JAX-RS: date fields are incorrectly marshalled

2 replies [Last post]
pljosh
Offline
Joined: 2006-12-05
Points: 0

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
blaise_doughan
Offline
Joined: 2003-09-30
Points: 0

Hi Witold,

*EclipseLink MOXy * 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 properties = new HashMap(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 >
>>> *Subject: **JAX-RS: date fields are incorrectly marshalled*
>>> *Date: *August 19, 2013 3:06:44 PM PDT
>>> *To: *users@glassfish.java.net
>>> *Reply-To: *users@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

pljosh
Offline
Joined: 2006-12-05
Points: 0

Thank you for pointing the bug tracker number and a workaround.
I hope the bug (or.... a nasty feature) is going to be resolved soon.

Regards,
Witold Szczerba