You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Giljo Scaria (JIRA)" <ax...@ws.apache.org> on 2007/06/07 02:24:26 UTC
[jira] Created: (AXIS-2673) Axis CalendarSerializer ignores the
TimeZone while formatting the date
Axis CalendarSerializer ignores the TimeZone while formatting the date
----------------------------------------------------------------------
Key: AXIS-2673
URL: https://issues.apache.org/jira/browse/AXIS-2673
Project: Axis
Issue Type: Bug
Components: Serialization/Deserialization
Reporter: Giljo Scaria
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as it is.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then cast it to java.util.Date .This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the date object is lost.
Axis then formats this date object with different timezone and results in incorrect time.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS-2673) Axis CalendarSerializer ignores the
TimeZone while formatting the date
Posted by "Giljo Scaria (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXIS-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Giljo Scaria updated AXIS-2673:
-------------------------------
Description:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then cast it to java.util.Date .This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the date object is lost.
Axis then formats this date object in the default timezone to GMT and results in incorrect time.
But the actual date/Calendar object was already in GMT.
was:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as it is.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then cast it to java.util.Date .This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the date object is lost.
Axis then formats this date object with different timezone and results in incorrect time.
> Axis CalendarSerializer ignores the TimeZone while formatting the date
> ----------------------------------------------------------------------
>
> Key: AXIS-2673
> URL: https://issues.apache.org/jira/browse/AXIS-2673
> Project: Axis
> Issue Type: Bug
> Components: Serialization/Deserialization
> Reporter: Giljo Scaria
>
> While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
> It always considers the date object to be in the default timezone.
> Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
> But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then cast it to java.util.Date .This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the date object is lost.
> Axis then formats this date object in the default timezone to GMT and results in incorrect time.
> But the actual date/Calendar object was already in GMT.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS-2673) Axis CalendarSerializer ignores the
TimeZone while formatting the date
Posted by "Giljo Scaria (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXIS-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Giljo Scaria updated AXIS-2673:
-------------------------------
Description:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then uses Calendar.getTime() to get the Date.This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the Calendar object is lost.
The issue is that the Date returned by Calendar.getTime() doesn't maintain the calendar's time zone , and developers at sun says this is by design.
Axis then formats this date object to GMT and results in incorrect time.
But the actual Calendar object passed in was already in GMT.
Axis should have taken care of checking the Calendar's Timezone and format the date accordingly, instead of blindly believing it to be in the default TimeZone Date.
was:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then cast it to java.util.Date .This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the date object is lost.
Axis then formats this date object in the default timezone to GMT and results in incorrect time.
But the actual date/Calendar object was already in GMT.
Affects Version/s: 1.4
> Axis CalendarSerializer ignores the TimeZone while formatting the date
> ----------------------------------------------------------------------
>
> Key: AXIS-2673
> URL: https://issues.apache.org/jira/browse/AXIS-2673
> Project: Axis
> Issue Type: Bug
> Components: Serialization/Deserialization
> Affects Versions: 1.4
> Reporter: Giljo Scaria
>
> While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
> It always considers the date object to be in the default timezone.
> Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
> But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then uses Calendar.getTime() to get the Date.This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the Calendar object is lost.
> The issue is that the Date returned by Calendar.getTime() doesn't maintain the calendar's time zone , and developers at sun says this is by design.
> Axis then formats this date object to GMT and results in incorrect time.
> But the actual Calendar object passed in was already in GMT.
> Axis should have taken care of checking the Calendar's Timezone and format the date accordingly, instead of blindly believing it to be in the default TimeZone Date.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS-2673) Axis CalendarSerializer ignores the
TimeZone while formatting the date
Posted by "Giljo Scaria (JIRA)" <ax...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/AXIS-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Giljo Scaria updated AXIS-2673:
-------------------------------
Description:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then uses Calendar.getTime() to get the Date.This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the Calendar object is lost.
The issue is that the Date returned by Calendar.getTime() doesn't maintain the calendar's time zone , and developers at sun says this is by design.
Axis then formats this date object to GMT and results in incorrect time.
But the actual Calendar object passed in was already in GMT.
Axis should have taken care of checking the Calendar's Timezone and format the date accordingly, instead of blindly believing it to be in the default TimeZone.
was:
While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
It always considers the date object to be in the default timezone.
Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then uses Calendar.getTime() to get the Date.This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the Calendar object is lost.
The issue is that the Date returned by Calendar.getTime() doesn't maintain the calendar's time zone , and developers at sun says this is by design.
Axis then formats this date object to GMT and results in incorrect time.
But the actual Calendar object passed in was already in GMT.
Axis should have taken care of checking the Calendar's Timezone and format the date accordingly, instead of blindly believing it to be in the default TimeZone Date.
> Axis CalendarSerializer ignores the TimeZone while formatting the date
> ----------------------------------------------------------------------
>
> Key: AXIS-2673
> URL: https://issues.apache.org/jira/browse/AXIS-2673
> Project: Axis
> Issue Type: Bug
> Components: Serialization/Deserialization
> Affects Versions: 1.4
> Reporter: Giljo Scaria
>
> While serializing java.util.Calendar object CalendarSerializer class ignores the Timezone set in the calendar object.
> It always considers the date object to be in the default timezone.
> Default behaviour of Axis is to convert the date to GMT.But if the passed in date or calendar object is already in GMT timezone, it should preserve the time as such.
> But getValueAsString(Object value, SerializationContext context) method in the CalendarSerializer takes in a parameter of Object type, and then uses Calendar.getTime() to get the Date.This results in creating a new java.util.Date object with default timezone and hence the original Timeone associated with the Calendar object is lost.
> The issue is that the Date returned by Calendar.getTime() doesn't maintain the calendar's time zone , and developers at sun says this is by design.
> Axis then formats this date object to GMT and results in incorrect time.
> But the actual Calendar object passed in was already in GMT.
> Axis should have taken care of checking the Calendar's Timezone and format the date accordingly, instead of blindly believing it to be in the default TimeZone.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org