aspose file tools*
The moose likes Java in General and the fly likes DST issue with GregorianCalendar Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "DST issue with GregorianCalendar" Watch "DST issue with GregorianCalendar" New topic
Author

DST issue with GregorianCalendar

Chintan B Shah
Ranch Hand

Joined: Sep 23, 2008
Posts: 83
Hello all,

I was under the impression that Java takes care of DST automatically, but looks like it doesnt.

I am accessing a web-service which returns the time in XMLGregorianCalendar format.

e.g. 3rd party application stores date as "12/11/2011 8:45:00 AM". When accessing their service and then using below code to convert to "Date" object, I get the time as "12/11/2011 7:45:00 AM"



Now, I did verify that details within XMLGregorianCalendar are correct(using getMonth(), get Day() etc. API's)), however once I convert it to GregorianCalendar it messes up.

This same code was working before DST.

FYI, I do not specify any timezone anywhere in code.

Any help on resolving this issue is much appreciated.

Thanks
Chintan.


SCJA 1.0
John Jai
Bartender

Joined: May 31, 2011
Posts: 1776
Can you post the input String you get from the webservice and the lines of code you use to convert them back to Date object?
Chintan B Shah
Ranch Hand

Joined: Sep 23, 2008
Posts: 83
Hi John,

Not sure what you mean by input String..web-service returns XMLGregorianCalendar. There is no string involved here.

In SOAP Envelope, date comes like this(sample)
<ns0:Create_Date>2011-11-09T05:00:00-07:00</ns0:Create_Date>

I am using JAX-WS Library to generate stubs for that web-service.

Once I get the date in form of XMLGregorianCalendar object from web-service, I used the code mentioned above to convert it to an actual "Date" object in java.

Thanks
Chintan.
Chintan B Shah
Ranch Hand

Joined: Sep 23, 2008
Posts: 83
Ok...so the below code worked out!


which makes me think if there is something wrong with using toGregorianCalendar()?



Using new() with GregorianCalendar works fine whereas "toGregorianCalendar()" failed in my case.

Any opinions/thoughts?


Thanks
Chintan.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1030
    
    5

It would be worth exploring the difference between the 2 approaches.

The API docs for the toGregorianCalendar method state:

A notable difference between XML Schema 1.0 date/time datatypes and java.util.GregorianCalendar is that Timezone value is optional for date/time datatypes and it is a required field for java.util.GregorianCalendar. See javadoc for java.util.TimeZone.getDefault() on how the default is determined.


The fact that you don't set a timezone may be the problem.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8159
    
  23

Chintan B Shah wrote:Hi John,

Not sure what you mean by input String..web-service returns XMLGregorianCalendar. There is no string involved here.

In SOAP Envelope, date comes like this(sample)
<ns0:Create_Date>2011-11-09T05:00:00-07:00</ns0:Create_Date>

I wouldn't stake my life on it, but I'm pretty sure that the "-07:00" is the problem. I suspect very strongly that GregorianCalendar will interpret that as GMT-7 (which makes sense, since it's defined in the XML schema as an offset from UTC), which does not use DST (no timezone based on GMT does).
It's also highly likely that when you use an XML method to read it, it converts the date it reads to the local timezone unless you tell it not to.

How to correct it - Have you tried what James suggested? Read the date in as you have, and then run setTimeZone() to set the time zone to whatever you need.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8159
    
  23

Chintan B Shah wrote:e.g. 3rd party application stores date as "12/11/2011 8:45:00 AM". When accessing their service and then using below code to convert to "Date" object, I get the time as "12/11/2011 7:45:00 AM"

Another question: Are you sure this is DST related? I was under the impression that the US and Canada (and I'm assuming that's where you are, based on the SOAP data you posted) changed back from DST on the 6th of November this year, so there shouldn't be any discrepancy.

Winston
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Chintan, what time zone are you actually in? I suspect Winston is correct, and the "-7:00" is a problem. But it's hard to tell without knowing where you are.

Winston Gutkowski wrote:Another question: Are you sure this is DST related? I was under the impression that the US and Canada (and I'm assuming that's where you are, based on the SOAP data you posted) changed back from DST on the 6th of November this year, so there shouldn't be any discrepancy.

DST is over now in the US, true. But it could also be that the code was written to work with DST, and now that it's ended, that's why it doesn't work.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8159
    
  23

Mike Simmons wrote:DST is over now in the US, true. But it could also be that the code was written to work with DST, and now that it's ended, that's why it doesn't work.

My worry is that there might be a bug in the code that generated the date to begin with. If the date was generated when DST was in force and didn't take into account that it wouldn't be for the date being created, you could get a similar discrepancy.

However, probably better to check the obvious stuff first.

Winston
Chintan B Shah
Ranch Hand

Joined: Sep 23, 2008
Posts: 83
Hi everyone,

First of all, thanks so much for chiming in.

I am located in California and 3rd party server as well as my server(where this Gregorian calendar code runs) are located in PST timezone.

I did try adding timezones and actual Date value when it came out looked completely different(because I believe it takes date and then converts it to that timezone and then displays it).

Actually the user requirement is not to add any timezone to the date that is returned by 3rd party. If 3rd party is sending, "12/101/2011 1:00:00 PM", I need to have that same date without using any timezone.

What bugs me is why was it working before DST and all of sudden it was off by an hour after DST?

Sorry if I am sounding a lot like non-programmer here


Thanks
Chintan.

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
OK, so who is it who creates this string?

Because that's saying the time is in GMT-7. And the thing is, Pacific Standard Time is GMT-8. Pacific Daylight Time was GMT-7. And Mountain Standard Time is also GMT-7. But Pacific Standard Time is GMT-8. So if there's an application saying you're using GMT-7, that application is wrong. Or that application has failed to use the time zone you want to use. The basic options are:

1. If the application is under your control, fix it.
2. If the application is not under your control (it's the third-party app), tell the third party to fix it.
3. If that doesn't work, put in a hack on your side to simply subtract 1 hour from the time if DST is not active, to correct the third-party app.
4. Or, convince yourself and your manager that this is all OK. Maybe the third party is in Denver, and 8:45 AM for them really is 7:45 AM for you.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18868
    
    8

Chintan B Shah wrote:Actually the user requirement is not to add any timezone to the date that is returned by 3rd party. If 3rd party is sending, "12/101/2011 1:00:00 PM", I need to have that same date without using any timezone.


But unfortunately that's a nonsensical requirement. You can't interpret a timestamp unless you interpret it with respect to some timezone. "1 PM" might mean "1 PM GMT" or "1 PM PST" or "1 PM America/Chicago" and so on for a long list of possible timezones.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Paul Clapham wrote:
Chintan B Shah wrote:Actually the user requirement is not to add any timezone to the date that is returned by 3rd party. If 3rd party is sending, "12/101/2011 1:00:00 PM", I need to have that same date without using any timezone.


But unfortunately that's a nonsensical requirement. You can't interpret a timestamp unless you interpret it with respect to some timezone. "1 PM" might mean "1 PM GMT" or "1 PM PST" or "1 PM America/Chicago" and so on for a long list of possible timezones.


Indeed. The only way something like that can work (short of a lot of really lucky guessing) is if the generators and consumers of the timestamp are all in the same TZ and don't care if time T looks like T +/- 1 when crossing a DST barrier, or if the times are only for human consumption, and are not actually used by any software. In this case, you might be able to get this to work by always setting/assuming GMT, and stripping off the TZ for all string-ified versions of the Date.

Note, however, that this is a huge hack, terribly brittle, and absolutely the wrong way to address this problem.

You might have a bit better luck with Joda time, which includes the concept of TZ-less time or local time, I think. However, you can still run into the same kinds of issues if your use-case isn't suitable for those constructs. The library just makes it less of a hack to handle the time when you do have an appropriate use-case.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8159
    
  23

Mike Simmons wrote:Because that's saying the time is in GMT-7. And the thing is, Pacific Standard Time is GMT-8. Pacific Daylight Time was GMT-7...

Exactly my point; the date says -0700, which is PDT, but the date itself (Nov. 9th, according to to the one XML date we've been shown) is after PDT finished. My worry was that maybe it was a future date generated before Nov. 6th, but maybe the code generating the date is just plain wrong.

@Chintan: My suggestion would be to generate ALL timestamps as GMT, and sort out the local display stuff afterwards.

Winston
H Paul
Ranch Hand

Joined: Jul 26, 2011
Posts: 471
    
    4
I did not follow the entire discussion. Some where I read:

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:
Mike Simmons wrote:Because that's saying the time is in GMT-7. And the thing is, Pacific Standard Time is GMT-8. Pacific Daylight Time was GMT-7...

Exactly my point;

Yes, we're in agreement here. I was just amplifying this point now that he's confirmed he's trying to use Pacific Standard Time.

Winston Gutkowski wrote:the date says -0700, which is PDT, but the date itself (Nov. 9th, according to to the one XML date we've been shown) is after PDT finished. My worry was that maybe it was a future date created before Nov. 6th, but maybe the code generating the date is just plain wrong.

I would say it's wrong, regardless of when it was generated. Date code needs to handle the time zone based on the date it's talking about, not the date it's executing. And the Java date classes normally handle this automatically, as long as they aren't misconfigured.

I'm guessing the most likely problem is that someone hard-coded something to use GMT-7, not realizing that it would be wrong once DST ended. In any event, the preferred solution is to fix the thing that's printing "-7:00", if it's supposed to be running in Pacific Standard Time.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
H Paul wrote:I did not follow the entire discussion. Some where I read:


And?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:@Chintan: My suggestion would be to generate ALL timestamps as GMT, and sort out the local display stuff afterwards.

That works, as long as stupid humans don't look at the generated files and wonder why you're changing the timezone. (We aren't, of course, but it's a PITA to explain this to people.)

Or generate them all in PST/PDT (whichever is appropriate depending on date), and display the correct GMT offset as well (which would be -8:00 in PST). That way the info is correct and also not upsetting to the stupid humans.

To be clear, the stupid humans I'm talking about here are the people who say you should not add any time zone to the date being returned by the third party. As Paul said, that's a nonsense requirement.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8159
    
  23

Mike Simmons wrote:Or generate them all in PST/PDT (whichever is appropriate depending on date)...

I assume you mean for the date being generated. That was my worry: that it might be being determined based on the current date.

...and display the correct GMT offset as well (which would be -8:00 in PST). That way the info is correct and also not upsetting to the stupid humans.

Yup; certainly another way, and XML dates use the ISO format which uses offsets from UTC anyway, so there shouldn't be a problem. I'm just happier when I only have one timezone to deal with (did some work in the airline industry where all date/times are in GMT), and it can also be useful if you need to do any ordering on date/time.

Anyway, I'm pretty sure that the fault lies with the code that's generating the date; not the one that's reading it.

Winston
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:
Mike Simmons wrote:Or generate them all in PST/PDT (whichever is appropriate depending on date)...

I assume you mean for the date being generated. That was my worry: that it might be being determined based on the current date.


Yes, as I said explicitly two posts back. But it sounds like we're making the same points to each other, and we agree that the code generating the -7:00 timestamp is most likely at fault.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

I think you are missing a fundamental problem, or design feature of Java's Date class. A Java Date does not have a timezone. A Format for a Java date has the format. The Date itself contains just the milliseconds since a date long ago. The reason that the Calendar and GregorianCalendar classes were added was that the mainline Java Date really sucked at handling anything about outputting or inputting values.
Chintan B Shah
Ranch Hand

Joined: Sep 23, 2008
Posts: 83
Mike and Winston, I think you guys hit the nail right on the head. Bottom line, I will research more with the 3rd party on why they are returning -7 instead of -8 in SOAP Envelope.

Thanks everyone for your time and valuable input on this thread.

Regards,
Chintan.
H Paul
Ranch Hand

Joined: Jul 26, 2011
Posts: 471
    
    4
"He who asks is a fool for five minutes, but he who does not ask remains a fool forever."

Let me be a fool for at least five minutes. I don't mind.

I'm not sure what question/issue that I should be asking but I did 1 quick test to understand how things work. I may ask some questions as we go along the way.

Is the output work as epxected? See point 2.2

Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18868
    
    8

I haven't looked at the code or the output, but yes, it's working as expected. Or at least, it's working the way it should be working. And I always start out by expecting that Java code will work the way it should work. So, yes.

But perhaps when you said "as expected" you meant something different than what I just described?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DST issue with GregorianCalendar