CODEWITHSUNDEEP
javadate
Kevin Bowersox
Kevin Bowersox

Reputation: 94459

Java Date Math Issue

I have the following snippet of code that determines if a job is within its runtimes:

private boolean isDuringRuntime(Job job) {

    Date now = new Date();

    System.out.println(DateUtil.getToday());
    System.out.println(job.getStartTime().toString());
    System.out.println(job.getEndTime().toString());

    Date startTime = new Date(job.getStartTime().getTime() 
                                      + DateUtil.getToday().getTime());

    Date endTime = new Date(job.getEndTime().getTime() 
                                      + DateUtil.getToday().getTime());


    System.out.println("Start Time: " + startTime.toString());
    System.out.println("Stop Time: " + endTime.toString());

    return now.after(startTime) && now.before(endTime);
}

DateUtil.getToday()

public static Date getToday() {
    Date now = new Date();
    Calendar cal = Calendar.getInstance();
    cal.setTime(now);

    cal.set(Calendar.HOUR_OF_DAY, 0);
    cal.set(Calendar.MINUTE, 0);
    cal.set(Calendar.SECOND, 0);
    cal.set(Calendar.MILLISECOND, 0);

    return cal.getTime();
}

Here is the output of one run:

Sun Jul 14 00:00:00 EDT 2013 //This is DateUtil.getToday();
1970-01-01 13:15:00.0  //Raw Start Time
1970-01-01 18:15:00.0  //Raw End Time
Start Time: Sun Jul 14 18:15:00 EDT 2013  //Computed Start Time 
Stop Time: Sun Jul 14 23:15:00 EDT 2013   //Computed End Time

I am not sure why the computed start time and computed end times are five hours ahead. I would expect that Start Time would be Sun Jul 14 13:15:00 EDT 2013 and End Time would be Sun Jul 14 18:15:00 EDT 2013.

Can anyone point out where I am going wrong? I'm not intimately familiar with Date and I suspect I'm overlooking something simple.

Upvotes: 2

Views: 588

Answers (2)

jahroy
jahroy

Reputation: 22692

What is the meaning of the Date fields in your job object?

I get the feeling you're trying to represent a "time of day" with a date object.

This is probably not a good idea.

If you want a job to run 6 hours into the day, I would store a long that represents 6 hours in millis:

static final long ONE_HOUR = 1000L * 60L * 60L;

Date today = DateUtil.getToday();
Date todayExecTime = new Date(today.getTime() + 6 * ONE_HOUR);

Of course, if your locale uses daylight saving time, this method could be off by an hour twice per year (if your exec time is after the change in time, which is usually early in the morning). If you just want JobA to run 6 hours into the day (rather than running at 6:00AM) it won't matter.

If this is a small piece of a more complicated scheduling system, you might want to look into using a library.

I've never used one, but I hear people talking about Quartz all the time.

Upvotes: 2

scottb
scottb

Reputation: 10084

Understand that Dates do not wrap fully localized datetimes that reflect the current reportable time in your locale.

A Date is a (mutable) wrapper around a long integer that is the number of milliseconds that have elapsed since January 1, 1970 UTC. Note that the long reflects UTC (as best as your system understand it, but almost all systems these days are synchronized after a fashion with some kind of network time service), and not your time zone.

When mapping a Date to a localized datetime string, you'll need to make sure that the Calendar that you are using knows that it needs to map from UTC to, say, EST (plus or minus DST if applicable). The problem you're describing sounds like a time zone mapping issue, and the Calendar instance you create is not initialized with a TimeZone.

Upvotes: 1

Related Questions