Re: Daylight savings problem in Australia

Tue, 10 Mar 2009 00:36:06 -0700 

Hi Felix,
There's really no correct result on this, since your dateTime value doesn't specify a time zone offset. If you want a dateTime value to be handled consistently, always use a time zone offset (which may be 'Z', meaning 0 offset from UTC) in the XML representation - so fix the web service server to do this. I haven't checked lately, but Axis2 should handle values with time zone offsets properly (meaning they get converted to that UTC value). If you can't change the server, the next best approach is to just treat the value as an xs:string in the schema and handle the conversion in your own code, where you can make whatever assumptions you want about the time zone. 


I've got an article on InfoQ which discusses some of the issues around 
schema's poorly thought-out data types for time and other basic data 
type issues for web services: 
http://www.infoq.com/articles/schema-for-ws-part1 The second one in this 
series should be out soon, discussing schema extensibility.


Cheers,

 - Dennis

Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117



Felix Castanar wrote:

Anyone help out there?

If I have this:

<LocalStartTime>2009-02-26T19:10:00</LocalStartTime>

Why does Axis2 returns one hour more during daylight savings (20:10 instead of 
19:10)?

Shouldn't return always the same date?

Cheers!
Felix

-----Original Message-----

From: Felix Castanar [mailto:[email protected]] 
Sent: Friday, 27 February 2009 12:52 PM

To: [email protected]
Subject: Daylight savings problem in Australia

Hi,

I'm in Sydney (Australia) where actually there is daylight savings (DST).
The problem I have is the following:

I'm accessing a web service server (in Australia) which sends the following:
<LocalStartTime>2009-02-26T19:10:00</LocalStartTime>

But the response object (generated using Axis2 1.4.1) creates a Calendar object 
that is equivalent to:

2009-02-26 20:10:00

(so it added one hour to what it was sent)

Since this conversion was working in Axis2 1.0 I investigated the issue.


This is the calendar object returned by Axis2 1.0 (please note the value for the 
last field: DST_OFFSET=3600000)


java.util.GregorianCalendar[time=1235635800000,areFieldsSet=true,areAllFieldsSet=true,
lenient=true,zone=sun.util.calendar.ZoneInfo[id="Australia/Sydney",offset=36000000,dstSavings=3600000,
useDaylight=true,transitions=142,lastRule=java.util.SimpleTimeZone[id=Australia/Sydney,offset=36000000,
dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=9,startDay=1,startDayOfWeek=1,
startTime=7200000,startTimeMode=1,endMode=3,endMonth=3,endDay=1,endDayOfWeek=1,endTime=7200000,
endTimeMode=1]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2009,MONTH=1,
WEEK_OF_YEAR=9,WEEK_OF_MONTH=4,DAY_OF_MONTH=26,DAY_OF_YEAR=57,DAY_OF_WEEK=5,
DAY_OF_WEEK_IN_MONTH=4,AM_PM=1,HOUR=7,HOUR_OF_DAY=19,MINUTE=10,SECOND=0,MILLISECOND=0,
ZONE_OFFSET=36000000,DST_OFFSET=3600000]

Whereas the same Calendar object returned by Axis2 1.4.1 returns:

java.util.GregorianCalendar[time=?,areFieldsSet=false,areAllFieldsSet=false,
lenient=true,zone=sun.util.calendar.ZoneInfo[id="Australia/Sydney",offset=36000000,dstSavings=3600000,
useDaylight=true,transitions=142,lastRule=java.util.SimpleTimeZone[id=Australia/Sydney,offset=36000000,
dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=9,startDay=1,startDayOfWeek=1,
startTime=7200000,startTimeMode=1,endMode=3,endMonth=3,endDay=1,endDayOfWeek=1,endTime=7200000,
endTimeMode=1]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=?,YEAR=2009,MONTH=1,
WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MONTH=26,DAY_OF_YEAR=?,DAY_OF_WEEK=?,
DAY_OF_WEEK_IN_MONTH=?,AM_PM=?,HOUR=?,HOUR_OF_DAY=19,MINUTE=10,SECOND=0,MILLISECOND=0,
ZONE_OFFSET=36000000,DST_OFFSET=0]

Note the last field for this version: DST_OFFSET=0

I dig down the source code till I found the method responsible for the conversion from 
"2009-02-26T19:10:00" to the Calendar object.

This method is "public static Calendar convertToDateTime(String source) " in 
the class org.apache.axis2.databinding.utils.ConvertUtils

This method explicitly sets DST_OFFSSET=0 regardless the TimeZone being in DST or not, so 
for the entry "2009-02-26T19:10:00" I will get one extra added in DST but the 
correct time when DST finishes (I already tested it changing my computer's clock).

I'm aware that JIRA issue 3916 
(https://issues.apache.org/jira/browse/AXIS2-3916) introduced the code where 
DST_OFFSET is set always to 0.


So... 
a) This is still a problem and the issue 3916 should be reopened

b) The web service should be sending the dates in a way we get the right time regardless 
of the DST. Any suggestion how? (AFAIK "2009-02-26T19:10:00" is the correct way)

It would be great if someone could put some light here.

Thanks
Felix








  






















					Reply via email to