I'm working on a scheduling application and am trying to understand how time, dates, etc, are normally represented in Java programs. In my application I'm typically scheduling lots of "short" duration things (a few minutes in duration) over the course of 1-2 days. Time is quantized to second level precision for the application.
Typically I envision storing an eventDate and a startTime for each Schedule; each "Scheduleable" item will be able to report its duration.
The eventDate would appear to be a Date object. The others I'm not too sure about... Is it normal to just represent times and time durations as integer seconds/milliseconds, or as Dates on the zeroth day, etc? The java.sql.Time class doesn't appear too useful outside the realm of DB applications.
If all I really care about is number of seconds ,minutes, and hours (even if the number of hours is greater than 24), would I be better off creating my own Time and TimeDuration classes? Of course falling back on Calendar and Date for converting to locale aware, etc displays and/or day-wrapping when needed....
Well, I say stick with what is already in the APIs rather than creating something form scratch. The Date and Calendar classes are more powerful that you think. It is just getting used to them. When I say Date I am talking about java.util.Date and not java.sql.Date.
I understand that the Date class is very powerful; but I don't understand how to use it for my needs.
Typically I only care about durations or about constraints such as "this event can not start before 1830" How do you use Date for "dateless times"? The date does not matter -- the date might not be fixed at the time that the schedule is being worked out. I understand that you can use Calendar with setTime and then add(Calendar.Seconds, durationInSeconds) to do the variaous calculations I'll need to do. So that would imply a simple int for storing duration should be sufficient, but it still needs the starting point Date; which won't be avaiable to me.
Given a single start time; I'll need to roll through all the events to find their start time given the durations and constraints. A typical schedule will involve hundreds of events being rolled up in this manner;
From what you describe, Eric, I'd probably avoid using a java.util.Date to represent any time that does not (yet) have a fixed date associated. Maybe create a class called Time which wraps an int which represents, say, milliseconds since midnight on an unknown date. Then write some methods which allow you to to things like, say, take a java.util.Date (reprensenting date only) and a Time, and create a new java.util.Date which represents the combined date & time. Or formats a time as some sort of string, etc.
Alternately, there are ways to use a Date to represent a time - but there are a number of subtle risks with this approach; it's easy for bugs to creep in because of the date part was forgotten about. Maybe one developer thought it was date only, and another thought it was date & time, and another thought time only, and another also thought time only but they were running the program in a different time zone than the rest of the team... Ugh. I'd rather create a new class with an unambiguous meaning, rather than change the meaning of an existing class (Date) and hope that everyone who sees the Date will have read your documentation on what that new meaning is.
"I'm not back." - Bill Harding, Twister
Joined: Dec 14, 2004
Thanks, Jim. I'm coming back to Java after many years with other languagees. I was a little surprised at how comprehensive some of the library support is for some things (such as Date) while nothing comprable for Time, etc. Partially I wanted to make sure I wasn't just missing something I should have seen.
I am not sure I see how you can have a time without a date for a scheduling application. But I haven't heard the whole story.
I had a similar problem with some of those drop down calendars where you had to pick a date, and it could never be blank or null, even though in our application that field wasn't mandatory.
Joined: Dec 14, 2004
Originally posted by Mark Spritzler: I am not sure I see how you can have a time without a date for a scheduling application. But I haven't heard the whole story.
Its kinda off-topic, but I'm working on a tool for helping (competition) organizers figure out how much time they need given different "layouts" of events. The organizers might not have booked a venue yet, perhaps they're tryng to decide between a large more expensive venue that would let them run more events simultaneously, or a smaller, cheaper venue that might require a second day, etc. In other cases, the organizer would have already booked the venue; for them its more a matter exploring the different was of filling the available time. But in either case the actual date is irrelevant.
The only place I can think of where the date matters would be for the few weekend competition that fall on one of the Daylight Savings Time transitions. However, the actual transition occurs between the days of the competition and doesn't affect the shceduleing of the events -- typically on the order of 0800-2200.
Its not scheduling like "appointments", its scheduling like workshop scheduling within a large conference -- a given workshop could be Day 1 hour 3, even if there is no mapping of "Day 1" to calendar day at the moment. In many ways its more "knapsack problem" like trying to fit X amounts of stuff into Y space, where X and Y are measured in time, not volume.