04-06-2010 03:28 PM
I'm new to the forum and to BB development. So please don't judge harshly if the answer to my question seem obvious.
I need to calculate the number of days until next birthday (given any valid birthdate)
After looking at the API and searching the forum, i realized that i could
calculate the difference between two dates in milliseconds and then devide the delta by value of one day in milliseconds. i.e:
date1 = birthdayCalendar.getTime().getTime();
date2 = System.currentTimeMillis();
delta = date1 - date2
numOfDays = delta\DateTimeUtilities.ONEDAY
Here is my question. How do i create a valid date1 with regards to leap years?
Maybe there is a better way to solve this?
Any help is greatly appreciated.
Solved! Go to Solution.
04-06-2010 07:15 PM - edited 04-06-2010 07:30 PM
Calendar Objects already compensate for leap years, so I do not think you have to do anything.
Setting a Calendar with the Year, Month, Day is exactly how I would recommend that you do it.
However note that DST could throw a curve ball at your calculations.
04-06-2010 08:24 PM
I guess my only worry with leap years is when i create date1 and it falls on February 29 non-leap year (invalid date).
As far as DST goes, is there anything i can do to avoid problems in my calculations?
04-06-2010 10:22 PM
04-07-2010 12:37 AM
It will not matter unless you are trying to count the number of hours, because I don't think the Calendar automatically accounts for the hour shift.
04-07-2010 11:23 AM
I agree that determining the number of days between today and Feb 29 could be a little difficult, if it is not a leap year. I suspect that the Calendar has some built-in mechanism to compensate for this, but that your solution of choosing a date is better.
DST does have a part to play and yes, the Calendar does compensate for it. Let us take two dates, say 1 March (before DST) and 1 June (after DST). If you take a calendar and set the same hour, minute etc, so they are all the same, except for the dates, then subtract one from the other, and then divide by the number of milliseconds in 1 hour, you are calculating the number of hours between the same time on two different days. You will find that there is not a multiple of 24 hours - because there is actually one hour less than the number of days since the clocks go forward (in the northern hemisphere anyway...),
In your case, you are not calculating the number of hours, you are calculating the number of days. But you will be dividing by [24 * (time in one hour)]. If you take[ 23 * (time in one hour)] and divide by [24 * (time in one hour)], using integer arithmetic, you will end up with 0. The easiest way to get round this, which also works for the end of DST too, is to just add one hour to the later date before you do the division.
Hope that makes sense....
04-07-2010 02:40 PM
Thanks Peter, It makes sense.I just have one question about your solution.
What did you mean by "works for the end of DST" ?
You add an hour only when one date is before DST and one date is after DST (when time mod 24 is not zero). Am i understanding this correctly?
04-07-2010 03:12 PM
You can add an hour to the later date whenever you like. Because you then divide by 24 hours, in the situation when there was no DST involved, or the dates span the end of DST (in which case there is an hour more rather than an hour short), it will still work - the remainder is dropped, so the extra hour(s) is(are) ignored.