I need to compare current time with the time that i am getting from database. I am getting time from database in Java class in java.sql.Time format (16:12:00).
I just need to display a error message if current time matches with the time present in DB.
When dealing with dates and times, you can use one of the many libraries like Joda Time, or you can simply consider a time as a given millisecond since 1/1/1970 (unix epoch), expressed as a normal long.
To convert a java.util.Date, or a java.sql.Time,Date etc.. that extends from java.util.Date, to a simple long, you can call getTime() : http://docs.oracle.com/javase/6/docs/api/java/util/Date.html#getTime()
Current time, expressed as milliseconds from unix epoch so comparable with results of getTime(), can be obtained with System.currentTimeMillis();
Once you have that, comparing it is very easy :
Time dbTime = // the time you obtained from the db
long dbLong = dbTime.getTime();
long now = System.currentTimeMillis();
if (dbLong < now) // data in the db is in the past
if (dbLong > now) // data in the db is in the future
if (dbLong == now) // data in the db is exactly now
Take care of the dbLong == now, cause it's precise to the millisecond, so it will rarely happen in practice, unless you use a range or reduce the precision, say, to the second or minute :
long dbLongSeconds = dbLong / 1000;
long dbLongMinutes = dbLong / (60*1000);
long nowSeconds = now / 1000;
long nowMinutes = now / (60*1000);
if (dbLongSeconds == nowSeconds) // data in the db is in this second
if (dbLongMinutes == nowMinutes) // data in the db is in this minute
If you need more sophisticated comparisons, like day or month, you should use either a library like Joda Time, or built in classes like Calendar, cause the math is way more complex given how western calendar divides the year.
To compare your current time with the time from the database you could simply construct a sql.Time from System.currentTimeMillis() and compare the two toString()s like so:
java.sql.Time serverTime = getServerTime();
java.sql.Time currentTime = new java.sql.Time(System.currentTimeMillis());
if(serverTime.toString().compareTo(currentTime.toString()) == 0)
{
//yay
}
else //nay
You could also compare the two sql.Time's directly using it's compareTo method, but this is trickier.
This is because even though sql.Time's setDate/Year/Month is deprecated and will throw an exception if you use them( which makes sense because they're not a date, only a time) the sql.Time's compareTo uses its superclass implementation, which means it compares not only the time but also the date, which sucks 'cus your database sql.Time object will probably always have the date 1970.01.01 whereas any sql.Time you construct off of System.currentTimeMillis() will have the current date. You can get around this by using a Calendar object as shown.
Calendar tmp = new GregorianCalendar();
tmp.setTimeInMillis(System.currentTimeMillis());
tmp.set(Calendar.YEAR, 1970);
tmp.set(Calendar.MONTH, 0); // 0 == January
tmp.set(Calendar.DATE, 1);
tmp.set(Calendar.MILLISECOND, 0);
java.sql.Time currentTime = new java.sql.Time(c.toInstant().toEpochMilli());
java.sql.Time serverTime = getServerTime();
if(currentTime.compareTo(serverTime) == 0)
{
//yay
}
else //nay
Or you could compare the long times directly as in Simone Gianni's answer, which would probably be the more efficient solution.
Related
I have many time stamps showing at which time a user entered the room. I want to calculate an average time. The problem occurs when some action happens at night.
I tried to calculate it with milis, but it is wrong.
ArrayList<String> times = new ArrayList<String>();
times.add("00:20:01");
times.add("00:00:01");
times.add("23:40:01");
times.add("23:20:01");
times.add("23:20:01");
times.add("00:20:01");
times.add("23:40:01");
times.add("23:40:01");
times.add("00:00:01");
long commonMillis=0;
for (String date:times){
LocalTime time = new LocalTime(date);
long dayMilis = time.getMillisOfDay();
commonMillis = commonMillis + dayMilis;
}
LocalTime average = new LocalTime(commonMillis/times.size());
This code, for example, returns the value 14:08:54.333. Because the hours 00:00 and 23:00 -- calculated in millis -- are too far from each other.
Please help me to find right way to calculate the average time?
Three things:
You have to define an offset time:
If you want an average of times of different days without knowing the day, you have to define an offset time by yourself. This time is used to decide whether a time is belonging to the next day or not.
This offset time may be derived depending on the values you get.
Without an offset time, you implicitely use 0 o'clock.
Avoid overflows:
If your times list gets longer, you may run into an overflow if a long field is not sufficient to store the accumulated value. You can use a data structure which is overflow resistant like BigInteger or use the (culmulative) moving average approach.
Wrong result constructor:
The constructor LocalTime(long instant) implicitely uses your local DateTimeZone to calculate a local time from an Instant. This causes different times when using the same code between different time zones.
The method you want to use is LocalTime#fromMillisOfDay.
Here is an approach considering the above points:
long movingAverage = 0;
// 1. define offset
LocalTime offset = new LocalTime("12:00:00");
long offsetMillis = offset.getMillisOfDay();
for (String date : times) {
long sampleMillis = new LocalTime(date).getMillisOfDay();
// align to offset
if (sampleMillis < offsetMillis)
sampleMillis += DateTimeConstants.MILLIS_PER_DAY;
long diff = sampleMillis - offsetMillis;
// 2. use moving average
movingAverage = movingAverage + diff / times.size();
}
// 3. avoid LocalTime(long) constructor
LocalTime result = offset.plusMillis((int) movingAverage);
System.out.println(result); // 23:48:54.329
A naive approach would be to gather the long millisecond values in all the dates, add them up and divide them by the number of dates, transforming them back into a LocalDate. You probably need a BigInteger to hold the sum, though.
In my app I create an object that represents a high school class. This object holds 2 Calendar objects that represents the class's start and stop time each day. When a user creates an assignment I want to check if the current time is between the two times of any of the classes. If it is I know that the assignment was created during that class. Here is my current code that does not work because .getTime() returns a date that includes month, and day, while I would just like to compare hours, and minutes. SO how can I trim the returned dates to just include the time in day? Would this be easier with joda-time, and if so what classes should be used?
public void checkTimeFrame() {
time = Calendar.getInstance().getTime();
ArrayList<SchoolClass> mList = mClassList;
// Changes index if assignment falls under time frame of class
for (int a = 0; a < mList.size(); a++) {
if (mList.get(a).getStartTime() != null && mList.get(a).getEndTime() != null &&
time.after(mList.get(a).getStartTime().getTime()) && time.before(mList.get(a)
.getEndTime().getTime())) {
index = a;
updateClassEditText();
}
}
}
JDK 8 Date-Time APIs are a good approach to solving these kinds of issues. Instead of Calendar , use LocalTime to store the start and end time of the class.
LocalTime now = LocalTime.now(ZoneId.systemDefault());
LocalTime start = mList.get(a).getStartTime();
LocalTime end = mList.get(a).getEndTime();
if(now.isAfter(start) && now.isBefore(end)){
//do something
}
For Android, you can use The ThreeTenABP project which adapts the java.time APIs for Android.
You can use Calendar.get(), as mentioned in another answer. To compare minutes, though, you should use Calendar.MINUTE, too:
int minutes_in_day = time.get(Calendar.HOUR_OF_DAY)*60 + time.get(Calendar.MINUTE);
Then, you can just compare the minutes within the day of the current time with that of the start and end times. This will, of course, only work when the times are in the same day.
The Calendar class has a get method where you can get different fields
e.g.
int hr = time.get(Calendar.HOUR_OF_DAY)
I will here only provide the Joda-Time-related answer you asked for. Joda-Time has the advantage to offer a dedicated type for the clock time, namely LocalTime. The old java.util.Calendar-stuff does not offer this advantage hence your difficulties.
First you convert an instance of java.util.Date like follows:
Date time = ...;
DateTime dt = new DateTime(time, DateTimeZone.getDefault());
LocalTime lt = dt.toLocalTime();
Note that the conversion is always timezone dependent. Then you can compare two LocalTime instances using the inherited methods isAfter(...) or isBefore(...).
try {
Date date1 = sdf.parse(given time);
Date date2 = sdf.parse("08:00 AM");
Date date3 = sdf.parse("06:00 PM");
if((date1.after(date2))&&(date1.before(date3))||date1.equals(date2) ||date1.equals(date3) ) {
}
} catch (ParseException e){
e.printStackTrace();
}
Calculating the difference between two dates (java.util.Date) in terms of no. of days look like very simple and we can find different ways to do that. I used the following code to calculate the date difference:
public static long daysBetween(Calendar startDate, Calendar endDate) {
Calendar date = (Calendar) startDate.clone();
long daysBetween = 0;
while (date.before(endDate)) {
date.add(Calendar.DAY_OF_MONTH, 1);
daysBetween++;
}
return daysBetween;
}
In main(), I used the following two dates :
Calendar c1 = Calendar.getInstance();
c1.set(2011, 1, 1);
Calendar c2 = Calendar.getInstance();
c2.set(2011, 1, 31);
long difference = daysBetween(c1, c2); //
But the value of the variable difference is not consistent. It is sometimes 30 and sometimes 31. So, why that might have happened.
Is there any solution to use the method results a consistent output ?
You're setting the date part of the calendars, but not the time part.
Sometimes the clock will tick between the calls to getInstance() and sometimes it won't, hence the inconsistency.
Options:
Set the time as well as the date, e.g. to midnight
Use a better date/time library - Joda Time - which has a more suitable representation (LocalDate). An important moral here is that if you can find a type which represents the exact information you have, and nothing else, that's likely to be a good fit and cause fewer complications.
Using LocalDate, you wouldn't even have to do the loop as Joda Time has good support for computing the differences between two values anyway.
LocalDate date1 = new LocalDate(2011, 1, 1);
LocalDate date2 = new LocalDate(2011, 1, 31);
Days period = Days.daysBetween(days1, days2);
int days = period.getDays();
You are only setting the year, month and day. The hours, minutes, seconds and milli-seconds are the current time (and thus different every time you run it)
I suggest you use Joda Time's LocalDate instead as it appears to does exactly what you want.
Hello I have this excerpt of code:
end = new DateTime(mergeToDateTime(this.endDate, this.empEndTime));
Duration extraTime = new Duration(this.preTime.getTime()); //add the first 30 mins
extraTime = extraTime.plus(new Duration(this.postTime.getTime())); //add the second 30 mins
end = end.plus(extraTime); // extraTime = -3600?
When I look in the debugger my durations are always coming up negative. I have no idea why this is, even though according to the API, it is possible to create a duration out of the a long type, hence the getTime(). (preTime and postTime are java.sql.Time types)
I guess your instances of java.sql.Time were created in such a way that their millisecond values include timezone offset.
For example, deprecated java.sql.Time(int hour, int minute, int second) constructor takes offset of the current timezone into account:
System.out.println(new Time(1, 0, 0).getTime()); // Prints -7200000 in UTC+3 timezone
It looks like timezone offset is introduced by JDBC driver, and it can be easily compensated by converting java.sql.Time to LocalTime (and vice versa):
LocalTime lt = new LocalTime(time);
Then you can convert LocalTime to duration:
Duration d = new Duration(lt.getMillisOfDay());
Aren't you starting out wrong when you use an instant in time as duration? The constructor signature you are using is Duration(long duration), not Duration(long startInstant) -- there is no such constructor, in fact.
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.