[
https://issues.apache.org/jira/browse/AXIS2-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Medric updated AXIS2-3059:
----------------------------------
Description:
I have an attribute of type xs:date in my WSDL and have generated ADBBean
objects via wsdl2java. This xs:date attribute maps to a DateTime field in our
database. However, our system only cares about the date part (month, day,
year), not the time. As a result, the dates are stored with time 00:00:00 in
the database. When querying for this object using axis2, it moves the day back
one day because of the UTC conversion that is done in
ConvertUtil.convertToDate(String).
For instance, the say the date is '2000-01-01 00:00:00' in the database. The
client is in GMT-5:00 time zone. What is returned to the client is '1999-12-31
19:00:00'. Essentially, it seems the day will always get shifted as per the
client time zone by way of the ConvertUtil.convertToString(Date) method that
always assumes GMT (which appends 'Z' to the serialized date). It seems to me
that the use of xsd:date is undermined here because the day will get always get
shifted back for any client timezones behind GMT. I'm not sure if this is a
bug or by design but it seems worth mentioning.
was:
I have an attribute of type xsd:date in my WSDL and have generated ADBBean
objects via wsdl2java. This xsd:date attribute maps to a DateTime field in our
database. However, our system only cares about the date part (month, day,
year), not the time. As a result, the dates are stored with time 00:00:00 in
the database. When querying for this object using axis2, it moves the day back
one day because of the UTC conversion that is done in
ConvertUtil.convertToDate(String).
For instance, the say the date is '2000-01-01 00:00:00' in the database. The
client is in GMT-5:00 time zone. What is returned to the client is '1999-12-31
19:00:00'. Essentially, it seems the day will always get shifted as per the
client time zone by way of the ConvertUtil.convertToString(Date) method that
always assumes GMT (which appends 'Z' to the serialized date). It seems to me
that the use of xsd:date is undermined here because the day will get always get
shifted back for any client timezones behind GMT. I'm not sure if this is a
bug or by design but it seems worth mentioning.
Summary: Date gets changed for xs:date types (was: Date gets changed
for xsd:date types)
> Date gets changed for xs:date types
> -----------------------------------
>
> Key: AXIS2-3059
> URL: https://issues.apache.org/jira/browse/AXIS2-3059
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: adb
> Affects Versions: 1.3
> Environment: Java 5.0 Windows XP
> Reporter: Michael Medric
> Assignee: Amila Chinthaka Suriarachchi
>
> I have an attribute of type xs:date in my WSDL and have generated ADBBean
> objects via wsdl2java. This xs:date attribute maps to a DateTime field in
> our database. However, our system only cares about the date part (month,
> day, year), not the time. As a result, the dates are stored with time
> 00:00:00 in the database. When querying for this object using axis2, it
> moves the day back one day because of the UTC conversion that is done in
> ConvertUtil.convertToDate(String).
> For instance, the say the date is '2000-01-01 00:00:00' in the database. The
> client is in GMT-5:00 time zone. What is returned to the client is
> '1999-12-31 19:00:00'. Essentially, it seems the day will always get shifted
> as per the client time zone by way of the ConvertUtil.convertToString(Date)
> method that always assumes GMT (which appends 'Z' to the serialized date).
> It seems to me that the use of xsd:date is undermined here because the day
> will get always get shifted back for any client timezones behind GMT. I'm
> not sure if this is a bug or by design but it seems worth mentioning.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
