Do you need
UtcTimeOfDay at all?
DateTime already has useful methods for working with paramterized times.
The disadvantage that using a raw
DateTime has is that you have no compile-time guarantee that you won't get an invalid
DateTime (e.g. one with a
Day component above 0). However, you can get the best of both worlds by having your class wrap a
public class UtcTimeOfDay
public readonly DateTime Value;
public UtcTimeOfDay(int hour, int minute, int second)
Value = new DateTime(0,0,0,hour,minute,second);
Now you get all the advantages of the rich functionality of
DateTime, along with the guarantees provided by your original class.
Regarding your original
UtcTimeOfDay, the names aren't great. Shouldn't
MinuteOfHour, and likewise shouldn't
This also reveals another problem: there's no guarantee that these values are valid (they could be negative, or above the maximum possible). This could be done with validation in a constructor, making the setters
UtcTimeInterval doesn't make any reference to the fact that it's specifically for a time interval within a day. Why not
While you can use
EndInclusive, a normal technique to deal with exclusive time spans is simply to add or subtract a tick to your time. So for example, if the inclusive start time was
startTimeInclusive, then if you want an exclusive version, that would be
startTimeExclusive = startTimeInclusive.AddTicks(1);
Being able to do this so simply is another benefit of using a
DateTime rather than trying to roll your own structure to represent the same thing.
So what I would do is remove the
EndInclusive properties, and do one of the following:
- Just let whoever sets the start and end
UtcTimeOfDay take responsibility for adding or subtracting a tick if they need to.
- Add a constructor with boolean
endInclusive parameters, as well as the start and end
UtcTimeOfDays which itself does the tick adding/subtracting when needed.
As a couple of people have noted in comments, using a
TimeSpan instead of a
DateTime may be preferable, as it is more in fitting with the meaning of these structures. This makes the add/subtract tick logic slightly more verbose, but not prohibitively.