This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello All, I think I've found a glitch in the Gregorian Calendar Class or else I'm just missing a piece of logic somewhere in my app. I'll explain my dilemma... First I create a Gregorian Calendar Object depending upon user Selection of dates....
What I'm trying to do is isolate the week dates surrounding the date selected by the user. So I roll the date to the beginning of the week to get the 'startDate'
The weird part is that when I roll back in the first week of April-2001(ONLY), the function skips April Second (which happens to be the 'DAY_OF_WEEK == 1' and then it continues to roll back to the last sunday in March. After rolling to the Sunday or beginning of the week I then store the date in a variable and proceed to roll the date forward to Saturday or end of the week:
Now the really weird part is that during other years(2002 etc...) this works for the first week in April and set the date correctly, but rolling from the second week in April will now give the last week in March??? Please say someone has encountered this problem before or can shed some light because I've been working on this for some time now and can't seem to figure out why it's doing this? [ April 22, 2002: Message edited by: Desiree Morriseau ] [ April 22, 2002: Message edited by: Desiree Morriseau ]
Hi Desiree, You are mis-interpretting the roll functionality. You want the add functionality. selectedDate.add( selectedDate.DAY_OF_WEEK, -1 ); Then you will have no problems. This is a common mistake because the java docs can get confusing. Sun also had a bug submission on this and explained that the user was confused and roll worked correctly. It won't change larger fields. See the bug report Regards, Manfred.
hmmm. . . Interesting to note that in 2001 the switch to Daylight Savings Time was on April 1. When I get some time I will check the Bug Parade to see if there is something in there. Actuall, I think that this Bug/enhancement covers what you are running into.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Joined: Jan 09, 2001
Hi Cindy, It is actually any year before 2002 that the roll function fails for (it fails for every year from 1994 to 2001 that I tried anyway). It seems to work for 2002 though ... Interesting, Manfred.
Joined: Sep 29, 2000
Well, the work around for this seems to be exactly what you suggested in the first place (use add() instead). From Bug parade
At a transition between a standard time and daylight saving time, handling of calendar fields is ambiguous. It's necessary to be able to specify wall, standard, daylight saving time in GregorianCalendar to disambiguate fields and operations, such as add/roll. Refer to tm_isdst spec of mktime() in the C library. 28 Nov 2000, xxxxx@xxxxx -- 4248500 -> 4312621. ---------------- java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
I wrote a method that return the date for yesterday. It has been working fine all month, but failed today. I believe the roll() method has a bug. The code to demonstrate this is here:
When run, it produces this output: today: Wed Nov 01 10:18:52 PST 2000 yesterday: Thu Nov 30 10:18:52 PST 2000
As you can see today is 1-Nov-2000, but yesterday is 30-Nov-2000. It should be 31-Oct-2000. So I changed the program to use the add() method, instead of roll(). It looks like this
This version produces the following result: today: Wed Nov 01 10:23:07 PST 2000 yesterday: Tue Oct 31 10:23:07 PST 2000 Which is what I would expect. (Review ID: 111696) java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) I have a column in Oralce database of date type. I have a data as '01-04-2001 02:00:00' of the format 'dd-mm-yyyy hh24:mi:ss'. When i read the program in java using 3rd party JDBC driver, i am getting the value of the date field as '01-04-2001 01:00:00'. Any time between 2.00AM to 2.59AM is shifted by one hour automatically. I suspect it is due to day light saving option enabled in my system. But even if i disable the daylight saving option, it is happening like this.How can fix this bug? To explain this... I have two objects date and time separately showing the date and time for April 1st 2001 2 AM. I concatanated these two strings and parsed in to a Date object. Then the result shows again that it is 1st April 2001 1 AM, the same old result!!!. java.sql.Time time = rs.getTime(1); java.sql.Date date = rs.getDate(1); System.out.println(time.toString()); //02:00:00 System.out.println(date.toString()); //2001-04-01 SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss"); java.util.Date date1 = sdf.parse(date.toString().trim() + " " + time.toString().trim()); System.out.println(new Timestamp(date1.getTime()).toString()); //2001-04-01 01:00:00.0 (Review ID: 128200)
webbug BezugliyY dapoo BruceRi
Workaround Use the add() method, instead of roll(). (Review ID: 111696) Evaluation The following is from Solaris mktime man page. GregorianCalendar needs to support a similar interface to disambiguate given time. If tm_isdst is positive, the original values are assumed to be in the alternate timezone. If it turns out that the alternate timezone is not valid for the computed calendar time, then the components are adjusted to the main timezone. Likewise, if tm_isdst is zero, the original values are assumed to be in the main timezone and are converted to the alternate timezone if the main timezone is not valid. If tm_isdst is negative, mktime() attempts to determine whether the alternate timezone is in effect for the specified time. xxxxx@xxxxx 2000-02-15
Your Comments & Work-arounds (These are NOT written by Sun!)
We are seeing something similar where it is possible that an underlying Formatter is making the roll call. If the date falls on the Daylight savings day then it is bumped up by 1 day - this occurs consistently no matter which year is inserted (as long as the daylight savings date is accurate for that year) but only on this date (April 1 2001 / April 7 2002)