• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Time CompareTo

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oddly enough, the next thread in this selfsame forum might have some information pertinent to your problem.
 
Jon Parise
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic