Same arguments passed on the same method for the same object. It usually will display true, which is what I expect. But... sometimes it displays false. About 2-3 out of 100 times. What is wrong with this method that would be causing this behavior?
year, month, and day are instance variables containing "2012", "4", "1" respectively.
public boolean isInDateRange(String startDate, String endDate)
{
if(startDate == null || endDate == null){
return false;
}
Calendar today = Calendar.getInstance();
today.set(Integer.valueOf(year), Integer.valueOf(month), Integer.valueOf(day));
Calendar start = Calendar.getInstance();
//subtract 1 from the month parameter because java.util.Calendar's months
//go from 0 to 11 instead of 1 to 12.
start.set(Integer.valueOf(startDate.substring(0, 4)), Integer.valueOf(startDate.substring(5, 7)) - 1, Integer.valueOf(startDate.substring(8, 10)));
Calendar end = Calendar.getInstance();
end.set(Integer.valueOf(endDate.substring(0, 4)), (Integer.valueOf(endDate.substring(5, 7))) -1 , Integer.valueOf(endDate.substring(8, 10)));
return today.compareTo(start) >= 0 && today.compareTo(end) <= 0;
}
And here is what I am passing to it
calendarDetails.getTuesday().isInDateRange("2012-05-01 00:00:00", "2012-05-01 00:00:00")
You're ignoring the time in your calculations. On the few occasions that the millisecond ticks over between Calendar today = ... and Calendar start = ..., you end up with today, start, and end having the same value for the date, but the time of both start and end is ahead of today. Specifically, they're 1 ms ahead since you're using Calendar.getInstance(), which returns the current time, to build all three of them. So when that tick happens, today isn't between start and end. You should zero out the time if you don't care about it.
Post more information to help you better like for which inputs it is giving wrong result.
your program is working fine.
I think One Date can not be both greater than and less than other date.
You are passing same date in both the arguments. (2012-05-01 00:00:00).
Moreover you can debug yourself ,print dates whenever you are not getting expected results.
Related
I'm working on creating a method to show the difference in time between two dates. To do this, I am using Calendar, and subtracting the dates to receive the remaining number available. However, for some reason, it's returning unexpected results. Here is my method in an extended Date class:
public String getReadableTimeDifference(Date fromDate, boolean showMilliseconds) {
String[] result = new String[7];
Calendar calendar = Calendar.getInstance();
Calendar from = Calendar.getInstance();
calendar.setTime(this);
from.setTime(fromDate);
// The two dates are correct. using a polymorphic method getReadableTimeDifference(boolean),
// it supplies this method with the current date. "this" is always a date in the future.
// Let's say that "this" is a date 10 seconds in the future:
System.out.println(from.getTime());
System.out.println(this);
// Since it's 10 seconds in the future, it will print the same (2016):
System.out.println(calendar.get(Calendar.YEAR) + " " + from.get(Calendar.YEAR));
// It should subtract the from date (2016) from the existing date (2016)
calendar.add(Calendar.YEAR, -from.get(Calendar.YEAR));
calendar.add(Calendar.MONTH, -from.get(Calendar.MONTH));
calendar.add(Calendar.DATE, -from.get(Calendar.DATE));
calendar.add(Calendar.HOUR, -from.get(Calendar.HOUR));
calendar.add(Calendar.MINUTE, -from.get(Calendar.MINUTE));
calendar.add(Calendar.SECOND, -from.get(Calendar.SECOND));
calendar.add(Calendar.MILLISECOND, -from.get(Calendar.MILLISECOND));
// It should print "0" (because 2016-2016 = 0) but instead it prints 2.
System.out.println(calendar.get(Calendar.YEAR));
int years = Math.abs(calendar.get(Calendar.YEAR));
int months = Math.abs(calendar.get(Calendar.MONTH));
int days = Math.abs(calendar.get(Calendar.DATE));
int hours = Math.abs(calendar.get(Calendar.HOUR));
int minutes = Math.abs(calendar.get(Calendar.MINUTE));
int seconds = Math.abs(calendar.get(Calendar.SECOND));
int milliseconds = Math.abs(calendar.get(Calendar.MILLISECOND));
if (years > 0) {
result[0] = Utilities.prettyNumerate("year", years);
}
if (months > 0) {
result[1] = Utilities.prettyNumerate("month", months);
}
if (days > 0) {
result[2] = Utilities.prettyNumerate("day", days);
}
if (hours > 0) {
result[3] = Utilities.prettyNumerate("hour", hours);
}
if (minutes > 0) {
result[4] = Utilities.prettyNumerate("minute", minutes);
}
if (seconds > 0) {
result[5] = Utilities.prettyNumerate("second", seconds);
}
if (milliseconds > 0 && showMilliseconds) {
result[6] = Utilities.prettyNumerate("millisecond", milliseconds);
}
return Utilities.join(Utilities.clean(result), ", ", " and ");
}
prettyNumerate takes a number and appends an "s" to the end of the supplied string if it's over 1, under -1 or 0. clean cleans an array of any null or empty elements. join join's an array by a delimiter, and a final delimiter for the last element. The expected outcome should be:
10 seconds
But instead it's:
2 years, 11 months, 31 days and 10 seconds
Nothing else is being manipulated within this custom date. When I instantiate this custom date, after any custom code is completed I print out this.getTime() and it prints out the correct time in milliseconds, which is 10 seconds into the future as it should be.
The year field in Calendar object of Java is relative to the era. By setting the year to something less or equal to 0 the calendar automatically corrects this by switching the era (from AD to BC or from BC to AD). This behaviour is better known from the other fields. For example, if you set the month to something negative, the year gets decremented accordingly.
Those corrections aren't made individually but rather they are made all at once, usually when you call getTime() to read out the resulting date.
Therefore, if you subtract year 2016 from a date in 2016, it automatically gets corrected to 1st century BC. When you do more subtractions, the time actually reaches 2nd century BC.
As suggested in some comments, you will be better off using Joda time for your usecase.
I am trying to check if Current Hour falls in between 7AM and 10AM
I am doing it this way
Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
int hour = cal.get(Calendar.HOUR_OF_DAY);
if(hour >= 7 && hour <= 10)
{
}
Please tell me if this is a valid approach to follow
Yes that is a valid approach. You could also use the new Time API (needs Java 8)
import java.time.LocalTime;
...
int hour = LocalTime.now().getHour();
It's a bit shorter to get the hour. There is also an overloaded now(ZoneId zoneId) method.
Or make it a one liner with a temporal query (also needs Java 8):
Boolean isBetween7and10AM = LocalTime.now().query(date -> date.get(ChronoField.CLOCK_HOUR_OF_DAY) >=7 &&
date.get(ChronoField.CLOCK_HOUR_OF_DAY) < 10);
Yup. This looks fine. Remember that this Calendar field is dependent on the timezone.
BTW: Put the starting curly brace at the end of the previous line, since this is the common code formatting style.
:-)
In my app I´m saving when I last updated some data from my server.
Therefore I used:
long time = Calendar.getInstance().getTimeInMillis();
Now I want that the data is updated twice a year at 03.03 and 08.08.
How can I check wheater one of these two date boarders were crossed since last update?
Change them to time in mseconds and compare:
Calendar c = Calendar.getInstance();
c.set(Calendar.MONTH, Calendar.MARCH);
c.set(Calendar.DAY_OF_MONTH, 3);
long time2= c.getTimeInMillis();
c.set(Calendar.MONTH, Calendar.AUGUST);
c.set(Calendar.DAY_OF_MONTH, 8);
long time3= c.getTimeInMillis();
if(time>time2){
//Logic
if(time>time3){
//Logic
}
}
There is something very important which took me a while to figure it out and can be very helpful to people out there, if you are looking for an answer to any of the following questions this is for you:
Why is my date not showing correctly?
Why even when I set the time manually it is not showing right?
Why is the month and the year showing one day less than the one that I set?
For some reason Java sorts the months values like an array, what I mean is that for Java January is 0 and DECEMBER is 11. Same happens for the year, if you set December as month 12 and year as 2012, and then try to do a "system.out.println" of the month and the year, it will show my month as January and the year as 2013!!
so what should you do?
Calendar cal = new GregorianCalendar();
cal.set(2012, 11, 26); // the date I want to input is 26/12/2012 (for Java, 11 is December!)
NOW WHAT IS THE CORRECT WAY TO GET THAT DATE TO SEE IT ON THE SCREEN?
if you try to "system.out.println of yourCalendar.DATE, yourCalendar.MONTH and yourCalendar.YEAR," THAT WILL NOT SHOW YOU THE RIGHT DATE!!!!
If you want to display the dates you need to do the following:
System.out.println (calact.get (calact.DATE));
// displays day
System.out.println (calact.get (calact.MONTH)+1);
//add 1 remember it saves values from 0-11
System.out.println (calact.get (calact.YEAR));
// displays year
NOW IF YOU ARE HANDLING STRINGS THAT REPRESENT DATES, OR....
IF YOU NEED TO COMPARE DATES BETWEEN RANGES , LET'S SAY YOU NEED TO KNOW IF DATE "A" WILL TAKE PLACE WITHIN THE NEXT 10 DAYS....THIS....IS.....FOR....YOU!!
In my case I was working with a string that had format "15/07/2012", I needed to know if that date would take place within the next 10 days, therefore I had to do the following:
1 get that string date and transform it into a calendar ( StringTokenizer was used here )
this is very simple
StringTokenizer tokens=new StringTokenizer(myDateAsString, "/");
do nextToken and before returning the day, parse it as integer and return it.
Remember for month before returning substract 1.
I will post the code for the first you create the other two:
public int getMeD(String fecha){
int miDia = 0;
String tmd = "0";
StringTokenizer tokens=new StringTokenizer(fecha, "/");
tmd = tokens.nextToken();
miDia = Integer.parseInt(tmd);
return miDia;
}
2 THEN YOU CREATE THE CALENDAR
Calendar cal = new GregorianCalendar(); // calendar
String myDateAsString= "15/07/2012"; // my Date As String
int MYcald = getMeD(myDateAsString); // returns integer
int MYcalm = getMeM(myDateAsString); // returns integer
int MYcaly = getMeY(myDateAsString); // returns integer
cal.set(MYcaly, MYcalm, MYcald);
3 get my current date (TODAY)
Calendar curr = new GregorianCalendar(); // current cal
calact.setTimeInMillis(System.currentTimeMillis());
4 create temporal calendar to go into the future 10 days
Calendar caltemp = new GregorianCalendar(); // temp cal
caltemp.setTimeInMillis(System.currentTimeMillis());
caltemp.add(calact.DAY_OF_MONTH, 10); // we move into the future
5 compare among all 3 calendars
here basically you ask if the date that I was given is for sure taking place in the future AND (&&) IF the given date is also less than the future date which had 10 days more, then please show me "EVENT WILL TAKE PLACE FOR SURE WITHIN THE NEXT 10 DAYS!!" OTHERWISE SHOW ME:
"EVENT WILL NOT TAKE PLACE WITHIN THE NEXT 10 DAYS".
if((cal.getTimeInMillis() > curr.getTimeInMillis()) && (cal.getTimeInMillis()< curr.getTimeInMillis()))
{ System.out.println ("EVENT WILL TAKE PLACE FOR SURE WITHIN THE NEXT 10 DAYS!!");}
else
{ System.out.println ("EVENT WILL *NOT* TAKE PLACE WITHIN THE NEXT 10 DAYS");}
ALRIGHT GUYS AND GIRLS I HOPE THAT HELPS. A BIG HUG FOR YOU ALL AND GOOD LUCK WITH YOUR PROJECTS!
PEACE.
YOAV.
If the comparison should involve only the year, month and day then you can use this method for check if c1 is before c2. Ugly, but works.
public static boolean before(Calendar c1, Calendar c2){
int c1Year = c1.get(Calendar.YEAR);
int c1Month = c1.get(Calendar.MONTH);
int c1Day = c1.get(Calendar.DAY_OF_MONTH);
int c2Year = c2.get(Calendar.YEAR);
int c2Month = c2.get(Calendar.MONTH);
int c2Day = c2.get(Calendar.DAY_OF_MONTH);
if(c1Year<c2Year){
return true;
}else if (c1Year>c2Year){
return false;
}else{
if(c1Month>c2Month){
return false;
}else if(c1Month<c2Month){
return true;
}else{
return c1Day<c2Day;
}
}
}
used compareTo method ..and this returns integer value .if returns -ve the days before in current date else return +ve the days after come current date
Consider the following code to only determine if the time component of one Date object is before the time component of another Date object:
private boolean validStartStopTime( Date start, Date stop ) {
Calendar startCal = Calendar.getInstance();
Calendar stopCal = Calendar.getInstance();
startCal.clear();
stopCal.clear();
startCal.setTime( start );
stopCal.setTime( stop );
startCal.set( Calendar.YEAR, 2011 );
stopCal.set( Calendar.YEAR, 2011 );
startCal.set( Calendar.MONTH, 1 );
stopCal.set( Calendar.MONTH, 1 );
startCal.set( Calendar.DAY_OF_YEAR, 1 );
stopCal.set( Calendar.DAY_OF_YEAR, 1 );
return startCal.before( stopCal );
}
Would this insure that time comparison is correct? Is there a better alternative (Joda is not an option)? I believe that this is equivalent to setting the Calendar objects to current date/time and manually copying over the hour, minutes, and milliseconds component. You can assume that timezone are the same.
EDIT: To clarify what I mean by comparing only the time component of a Date object. I mean that when looking specifically at the time portion, the start time is before the stop time. The date portion is ABSOLUTELY irrelevant (in that start="Jan 2 20011 10AM" and end="Jan 1 2011 11AM" is perfectly fine), if I had a choice I'd simply use something that contained just the time but a Date object is what I'm given. I'd like to not write a sequence of if-else which is why I have the approach above but I welcome a cleaner/better approach.
Your code should work fine. You could also format just the time components in a zero-based string notation and compare them lexicographically:
public static boolean timeIsBefore(Date d1, Date d2) {
DateFormat f = new SimpleDateFormat("HH:mm:ss.SSS");
return f.format(d1).compareTo(f.format(d2)) < 0;
}
[Edit]
This is assuming that the dates have the same timezone offset. If not you'll have to adjust them manually beforehand (or as part of this function).
There are 86,400,000 milliseconds in a day, why not just use that to figure it out?
You could just mod timeInMilliseconds with that number and compare the results.
Please your opinion on the following code.
I need to calculate the diff in days between 2 Date objects. It is assured that both Date objects are within the same TimeZone.
public class DateUtils {
public final static long DAY_TIME_IN_MILLIS = 24 * 60 * 60 * 1000;
/**
* Compare between 2 dates in day resolution.
*
* #return positive integer if date1 > date2, negative if date1 < date2. 0 if they are equal.
*/
public static int datesDiffInDays(final Date date1, final Date date2){
long date1DaysMS = date1.getTime() - (date1.getTime() % DAY_TIME_IN_MILLIS);
long date2DaysMS = date2.getTime() - (date2.getTime() % DAY_TIME_IN_MILLIS);
long timeInMillisDiff = (date1DaysMS - date2DaysMS);
int ret = (int) (timeInMillisDiff / DAY_TIME_IN_MILLIS);
return ret;
}
Can you point to a problem that I might have missed ?
EDIT: #mmyers asked if pass my unit test. Well - Yes. But I have no real experience with dates and I know that is a big subject. Posted below the unit test that I'm using.
public class TestMLDateUtils {
#Test
public final void testDatesDiffInDays() {
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
// 00:00:00.000 1.1.1970
Calendar cal1970 = Calendar.getInstance();
cal1970.setTimeInMillis(0);
Calendar tested = Calendar.getInstance();
tested.setTimeInMillis(0);
// Add 1 millisecond, date = 00:00:00.001 1.1.1970
tested.add(Calendar.MILLISECOND, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == 0);
// Add 1 second, date = 00:00:01.001 1.1.1970
tested.add(Calendar.SECOND, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == 0);
// Add 1 minute, date = 00:01:01.001 1.1.1970
tested.add(Calendar.MINUTE, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == 0);
// Add 1 hour, date = 01:01:01.001 1.1.1970
tested.add(Calendar.HOUR_OF_DAY, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == 0);
// date = 23:59:59.999 1.1.1970
tested.setTimeInMillis(0);
tested.add(Calendar.MILLISECOND, 999);
tested.add(Calendar.SECOND, 59);
tested.add(Calendar.MINUTE, 59);
tested.add(Calendar.HOUR_OF_DAY, 23);
//System.out.println("D: " + tested.getTime());
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == 0);
// date = 00:00:00.000 2.1.1970
tested.setTimeInMillis(0);
tested.add(Calendar.DAY_OF_MONTH, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
// date = 00:00:00.001 2.1.1970
tested.add(Calendar.MILLISECOND, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
// date = 00:00:01.001 2.1.1970
tested.add(Calendar.SECOND, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
// date = 00:01:01.001 2.1.1970
tested.add(Calendar.MINUTE, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
// date = 01:01:01.001 2.1.1970
tested.add(Calendar.HOUR_OF_DAY, 1);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
// date = 13:01:01.001 2.1.1970
tested.add(Calendar.HOUR_OF_DAY, 12);
assertTrue(DateUtils.datesDiffInDays(cal1970.getTime(), tested.getTime()) == -1);
assertTrue(DateUtils.datesDiffInDays(tested.getTime(), cal1970.getTime()) == 1);
}
}
Immediate problem: days can have less than or more than 24 hours due to daylight saving time changes.
Secondary problem: normally when people think in days, they really mean "human days" rather than "periods of 24 hours". In other words, many people would say that 7pm-7am the next day is a difference of a day, whereas 7am-7pm the same day is a difference of zero days. Both are 12 hours. At that point, you really need to know the calendar that is being considered.
Of course, this may not matter for your situation, but we don't really know what that is.
Third problem: you're using the built-in calendar API instead of Joda Time. That's almost never a good idea - it's horrible and riddled with gotchas and problems. And yes, the regulars here will tell you that's always part of my answer when it comes to Java dates and times - and for good reason. It's really that important.
EDIT: Your test sets the default time zone to be UTC. That's not really a good idea (especially without resetting it in a finally statement). Time zones are tricky, but you should really think about what values you've got, what they mean, and what time zones are involved.
The time zone, if any, within the Date object is irrelevant, since you're using getTime(); that "[r]eturns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object."
However, you aren't accounting for leap seconds, which some implementations may return. Thus, if the day range you give has one or more leap seconds in it, and your times are near enough to the same time of day, your calculation may be wrong by a day. That said, there appears to be no way to see if any particular implementation accounts for leap seconds or not (I expect that most don't), and the difference is pretty darn trivial anyway.
There are many dimensions to a code review; rather than correctness, addressed by others, let me focus a little on style. This will of course be somewhat more subjective than a review concentrating on correctness.
I would inline the "ret" variable. It increases the size of the method without enhancing readability.
I would consider separating the conversion between milliseconds and days into a separate function. Your full class probably performs that division in multiple places. Even if not, it's helpful in that it's easier to name functions that do only one thing.
Speaking of naming, I would rename the function, perhaps to "dayDifference" - abbreviations cause many problems, not least of which is the difficulty of remember which abbreviation was used in which circumstance. If you use none, ever, that particular source of confusion is eliminated. Similarly, I would rename the constant to MILLISECONDS_PER_DAY.
Another problem which hasn't been mentioned yet is leap seconds. Days may have more or less than 24 * 60 * 60 seconds due to adjustments in UTC time to keep it more or less in synch with the mean solar year. Probably not a big deal for your usage, but you should at least be aware of the possibility.
A good API is what you need if you have non-trivial requirements for dealing with dates and times. The link to Joda Time in Jon Skeet's answer appears to be broken, so here is a link that does work.
Date already has this method, look up Date.compareTo(Date) in Javadoc.