Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calendar question

Status
Not open for further replies.

amethystct

Programmer
Jan 26, 2004
21
FR
I'm having issues setting a date and I'm wondering if someone could explain what I'm doing wrong. User enters a date/time. I need to compare that date/time to the current date/time and decide whether it meets criteria. The problem is that I have to assume the user entered the date/time based on their timezone, which is CST. My time is EST. It looks like it's creating the calendar as EST so it's throwing my tests off. I don't understand what I'm doing wrong with this.

int year = Integer.parseInt(varReqLOS.getEstRequestedDate().substring(6,10)) ;
int month = Integer.parseInt(varReqLOS.getEstRequestedDate().substring(0,2));
int day = Integer.parseInt(varReqLOS.getEstRequestedDate().substring(3,5)) ;
int hour = Integer.parseInt(varReqLOS.getEstRequestedTime().substring(0,2));
int minut = Integer.parseInt(varReqLOS.getEstRequestedTime().substring(3,5));

//SET CALENDAR WITH REQUESTED LOS DATE/TIME
Calendar varReqCal = new GregorianCalendar(year, month, day, hour, minut);
//SET CALENDAR WITH CURRENT DATE
//getTimeZone(NullUtility.checkNullString(varOrder.getFeDetail().getState()))
//Calendar varCurrentCal = new GregorianCalendar(TimeZone.getTimeZone("CST"));


String[] ids = TimeZone.getAvailableIDs(-6 * 60 * 60 * 1000);
// if no ids were returned, something is wrong. get out.
if (ids.length == 0)
System.exit(0);

// create a Central Standard Time time zone
SimpleTimeZone cst = new SimpleTimeZone(-6 * 60 * 60 * 1000, ids[0]);

// create a GregorianCalendar with the Central Daylight time zone
// and the current date and time
Calendar varCurrentCal = new GregorianCalendar(cst);
System.out.println("Current CST time: " + varCurrentCal.getTime().getTime()); // Should be in milliseconds and less than the next
java.util.Date varCurrDate = new java.util.Date();
varCurrentCal.setTime(varCurrDate);
System.out.println("Current, well should be, CST time: " + varCurrentCal.getTime().getTime()); // Could be setting to EST current time


//SET THE CURRENT DATE UTIL EQUAL TO THE DEFAULT CALENDAR TIME
//java.util.Date varCurrDate = varCurrentCal.getTime();
//this is being set to est, why?????
System.out.println("What is the los calendar for comparison: " + varCurrentCal.getTime().getTimeZone());

//SET THE REQUESTED DATE UTIL TO THE CALENDAR THAT WAS SET WITH REQUESTED LOS DATE/TIME
java.util.Date varReqDate = varReqCal.getTime();

//PUSH CURRENT DATE AHEAD BY TWO HOURS FOR COMPARISON
//varCurrentCal.add(Calendar.HOUR_OF_DAY, howManyHours);1 //kpt remove and addnext line
varCurrentCal.add(Calendar.HOUR, howManyHours);
//WHEN SETTING THE jave.util.Date TO THE REQUESTED DATE IT APPEARS TO
//BE ADDING 1 MONTH TO THE DATE TO MAKE UP FOR THE CALENDAR BASE ZERO
//NEED TO SUBTRACT 1 MONTH BEFORE COMPARING TO MAKE UP FOR IT.
//ONLY SEEMS TO DO THIS FOR THE CALENDAR THAT WAS SET MANUALLY and NOT THE INSTANCE OF
varReqCal.add(Calendar.MONTH, -1);

java.util.Date varReqDate2 = varReqCal.getTime();

//SET THE CURRENT DATE UTIL EQUAL TO THE DEFAULT CALENDAR TIME THAT WAS INCREMENTED
java.util.Date varCurrDate2 = varCurrentCal.getTime();
System.out.println("Added " + howManyHours +" hours what is it now ?" + varCurrDate2 + " what is the requested date: " +varReqDate2);
varReqCal.add(Calendar.MONTH, 1);//PUT IT BACK IN CASE IT IS NEEDED
//PUSH IT BACK AGAIN IN CASE THIS CHANGED THE DAY OR SOMETHING
varCurrentCal.add(Calendar.HOUR_OF_DAY, -howManyHours);
 
As near as I can tell, you are not doing anything wrong. TimeZone doesn't work with the Calendar object the way we expect it to.

I went so far as to take the source code for Calendar, GregorianCalendar etc and run it through a debugger. The GregorianCalendar object has a bug in it where the date it starts with already has the time zone offset added in to it (Offset from the current locales time zone, not GMT). Then the offset gets subtracted back off later in the calculation, resulting in an unchanged current date for the default time zone. I think what it's trying to do is to convert the current date to GMT time, then add the new timezone offset. But it doesn't work right.

I don't have a solution for you yet except perhaps to run the date through a DateFormat object (which works) and then reconstruct the milliseconds from the output...

I'm going to think about it some more. It seems like there's some aspect of this I've missed...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top