aspose file tools*
The moose likes JDBC and the fly likes Time CompareTo Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Time CompareTo" Watch "Time CompareTo" New topic
Author

Time CompareTo

Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
Hey everyone,

I have two Java.Sql.Time variables, one called startTime and one called endTime. The user passes them in to a function.

In that function I need to handle things differently depending on if startTime > endTime or not. Since time can wrap around, something could start at 9:00pm or 21:00:00 and end at 7am 7:00:00.

I use the following:

if(startTime.compareTo(endTime) < 0){
//Do Stuff
}

However, even when startTime is 0:00:00 and endTime is 23:00:00 I always get a 1 as the result of the compareTo call indicating that startTime is greater than endTime.

I'm not sure what the solution is, I tried turning the two times into GregorianCalendars, but I am not sure how.

Any help would be great!

Thanks!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38851
    
  23
Oddly enough, the next thread in this selfsame forum might have some information pertinent to your problem.
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
I did read that, and I am aware of the 3 types. I just don't understand why 4:00 is coming out as greater than 7:00...

I know java.sql.time is just a wrapper around Date so maybe the Date portions are different.

I think the easiest solution for me may be to just use String.Split to break the hours, mins and seconds out and do the comparison that way.

If anyone has a better method let me know.

Thanks,

Jon
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3704
    
    5

If you're desperate, I tend to move everything to epoch time (in long) since its easiest to do calculations with. The problem with a lot of date sql types is that they ignore set the time of day but not the day of year. The best solution, if possible, is to use the "TIMESTAMP" or "DATETIME" field in the database. Then, whenever you retrieve the record it will have both populated.


My Blog: Down Home Country Coding with Scott Selikoff
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

Originally posted by Jon Parise:
I know java.sql.time is just a wrapper around Date so maybe the Date portions are different.
Not according to the documentation. But maybe there's a timezone issue getting in the way. Anyway, I would go with Scott's suggestion of extracting the getTime() values and comparing those. (Actually just looking at them might tell you something.)
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
Thanks for the suggestion, I didn't think of comparing the get time values..perhaps by looking at them I will see something.


The reason I am using time is that this is for a production shift. So the user enters a shift name, start time, end time and the days of the week it is valid for.

The days of the week are taken care of by a String.

I really don't need a timestamp or a date in this case I just need a time. Nothing else matters in the variable. The date portion would have no meaning really in this instance.


I'll check the getTime() values when I get to work. At least I know I can fall back on the string split method, but it seems like an ugly hack.
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
Well I printed the results of the get time methods, here is what I get:

First Set:
Start:04:00:00Get Time: 32400000 End:00:07:00 Get Time:18420000

Second Set
Start:07:00:00Get Time: 43200000 End:04:00:00 Get Time:32400000

So something is making them behave strangely.

I'm using a PostgreSQL database version 8.2.

The table has both the columns created as time without a time zone. Here is my create table:



Anyone have any insights?
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3704
    
    5

If you're seeing something odd its probably related to time zone. Keep in mind everything is stored in UTC internally, but when its read it may be converted to what it 'thinks' is your local.

Make sure your viewing things in a consistent format such as UTC. That's part of why I prefer the epoch getTime() long value... its a number always calculated in UTC.
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
Originally posted by Scott Selikoff:
If you're seeing something odd its probably related to time zone. Keep in mind everything is stored in UTC internally, but when its read it may be converted to what it 'thinks' is your local.

Make sure your viewing things in a consistent format such as UTC. That's part of why I prefer the epoch getTime() long value... its a number always calculated in UTC.


What's odd though is in the database it is store specifically without a time zone. Also, the two columns are inserted at the exact same time...

Internally something is certainly different.
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
I figured it out.

In one obscure place buried deep in the code I had accidentally built my time as minute hour second...

That causes the problem.

I fixed that and now compareTo is working just fine. Funny how that works....

So the world is as it should be again and I am not going insane. Once again 4:00 is before 7:00.

Thanks to all those that helped!
[ August 29, 2008: Message edited by: Jon Parise ]
Jon Parise
Ranch Hand

Joined: Jul 03, 2007
Posts: 81
I actually thought it was fixed last time, but it showed up again.

After using the debugger it dawned on me what my issue was.

I was creating my times using the Calendar class and just using Calendar.getInstance(). The problem is that I get a different Year, month and day portion of the calendar each day it is run.

I now normalize the calendar and use it like so:



From there I created a new calendar with just the hour, minute and second portions changed:



Now 8:00:00 is always represented by the same long no matter when it is created.

Hopefully this helps someone else out someday.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Time CompareTo