Java Calendar issue

[Mojo Ku]

I have this problem with the java Calendar.

Here is the code break down:

Calendar startDate = GreogrianCalendar.getInstance(tz); //tz = time zone instance (GMT -7) in my case
startDate.getTime(startDateFromDB); // startDateFromDB is a Date from database (August 14th, 2008);
System.out.println(startDate.getTime().toString());
startDate.set(Calendar.HOUR_OF_DAY, 18); // Set time to 6:00PM (GMT -7)
System.out.println(startDate.getTime().toString());

The output:

Thu Aug 14 00:00:00 EDT 2008
Thu Aug 13 19:00:00 EDT 2008

I understand why the time is 1900 since the output is formated in my local time, but why is the day of month rolled back to 13th instead of staying the at 14 like it originally was?

[ August 14, 2008: Message edited by: Mojo Ku ]

[ August 14, 2008: Message edited by: Mojo Ku ]
[ August 14, 2008: Message edited by: Mojo Ku ]

[Mike Simmons]

The original startDateFromDB may appear as "Thu Aug 14 00:00:00 EDT 2008" to you on the east coast, but that's August 13 at 9 PM on the west coat (currently GMT-7) - which is what you told the Calendar to use. So when it resets the hour, it keeps the day of the month as 13.

[Mike Simmons]

Now, I can't see any reason why it should claim that Aug 13, 2008 was a Thursday. That's not true in any time zone. Is it possible you did not copy and paste correctly here?

[Mojo Ku]

Thanks Simmons. Sorry, I didn't copy/paste the code, i quickly wrote it out since i was using my laptop for coding and desktop for posting, so yes, it does say WED.

I believe you are correct, however, how do I fix this my problem?
From my understanding time is stored as milliseconds since 1970, so when I pull it out its relative to GMT time, then formatted to whatever local/timezone I am in.

With that said, I'm assuming that the set function will format the HOUR_OF_DAY relative to the timezone that the Calendar instance is set to. However it seems java is setting the time relative to the GMT time. Is this correct?

Is it just me or Java Calendars/Date seem kinda weak.

[Mike Simmons]

[MK]: I believe you are correct, however, how do I fix this my problem?

Well, the code is doing what you told it to do. I don't know enough about what you're trying to do here. Two possible simple fixes are:

1) Since the DB is apparently storing the date as midnight EDT, use a Calendar that's set to the EDT timezone. Which is apparently what you'll get by default anyway. Trying to use GMT-7 seems to be causing problems; why are you doing that? Try using the default time zone EDT and setting the hour of the day to 9 PM, which is 6 PM in PDT or GMT-7.

2) Just add 1 day to the Calendar result.

For both of these, you will probably want to test the results carefully. Does the DB ever have startDateFromDB which is set to a different time of day, or is it always midnight EDT (or EST)? Does the code work both during daylight saving time and in winter? You may need to specify some time zones differently to get it to work.

If those don't work for you, please describe exactly what you're trying to do here.

[MK]: From my understanding time is stored as milliseconds since 1970, so when I pull it out its relative to GMT time, then formatted to whatever local/timezone I am in.

That's true, although the GMT part isn't relevant here, I think - it's just an internal detail. Your problem is the mismatch between EDT and GMT-7.

[MK]: With that said, I'm assuming that the set function will format the HOUR_OF_DAY relative to the timezone that the Calendar instance is set to.

Yes.

[MK]: However it seems java is setting the time relative to the GMT time. Is this correct?

It's true, but I really don't think it's relevant here. Midnight on Aug 14 EDT is the same time as 9 PM Aug 13 in GMT-7, or 0400 Aug 14 GMT. Whether you see it as the 13th or 14th depends on what time zone you use to interpret it. E.g. using a DateFormat set to a particular TimeZone. Or using a Calendar as you are here. You've told the JVM to use GMT-7, so it sees the date as the 13th.

[MK]: Is it just me or Java Calendars/Date seem kinda weak.

Oh, they're hard to use; it's not just you. Partly that's because human timekeeping is more complex than many people realize, and partly that's because they're badly designed. Especially Calendar. But I think the issues you're having are not because of the design problems, but because time zones are inherently confusing. The design problems are mostly things we haven't talked about here.

[Mark Vedder]

 

Originally posted by Mike Simmons:

[MK]: Is it just me or Java Calendars/Date seem kinda weak.

Oh, they're hard to use; it's not just you. Partly that's because human timekeeping is more complex than many people realize, and partly that's because they're badly designed. Especially Calendar. But I think the issues you're having are not because of the design problems, but because time zones are inherently confusing. The design problems are mostly things we haven't talked about here.

Many have said the Java Calendar/Date APIs are confusing. Given the complexity of the task at hand; they did a good job. But some people still thought it was confusing, and felt in hindsight some things should be done differently. So they created a new Date & Time API called Joda Time. I've used it in a couple of projects. It has a slight learning curve, but overall it is more straight forward of an API. You might want to give it a try.

Mike is correct that time keeping is fair more complex than people realize. Dealing with leap years, leap seconds, and leap centuries alone can make things get complex fast. But there are many other things that have to be taken into consideration. For a very interesting read about such, take a look at Frequently Asked Questions about Calendars.
[ August 14, 2008: Message edited by: Mark Vedder ]

[Andrew Monkhouse]

Mike Simmons

Please check your private messages for an important administrative matter.

Thanks, Andrew