Paul Pladijs wrote:
>> ...
>
>
> In terms of object-oriented analysis, a time-object will mostly be
> considered as an attribute of a domain-object. Domain-objects (can)
> have methods to change their internal state (also called setters).
> ...
>
> Regards,
> Paul.
This is just a note about generalized time classes.
I have frequently found the need to track the time since a particular instant (usually 3:00 AM) without keeping track of the date, though I do need a weekday/Saturday/Sunday/Special indicator. Usually what I have done is keep track of minutes since the preceeding midnight. I have never found a useful time package, partially because I need to keep track of times until after 3:00 the next morning. Sometimes until as late as 06:00 the next morning. I usually use a print representation of 30:00 for that time, though occasionally I have used 06:00 XM. These times need to be manipulated as numbers (the actual application was bus schedules, time between stops, since the last bus, etc.).
Data packages that are firmly fixed relative to a particular date are much worse than useless under these circumstances. For instance 25:00 Saturday is still on the Saturday schedule, but if it were tied to a date then it would be seen as Sunday. Time packages that check boundary conditions ... well, any time after midnight would just be unacceptable to them. Etc.
If you are building a generalized time/date package, consider how you would handle cases such as scheduling, that isn't tied to the clock day, but rather to some different cycle. (E.g., I did do bounds checking. I didn't allow any time to be later than 36:00 or earlier than 03:00.)