Model interval inclusiveness in C#
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 DateTime:

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 MinuteOfDay be MinuteOfHour, and likewise shouldn't SecondOfDay be SecondOfMinute?

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 private. 



The name UtcTimeInterval doesn't make any reference to the fact that it's specifically for a time interval within a day. Why not UtcTimeOfDayInterval?



While you can use StartInclusive and 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 StartInclusive and 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 startInclusive and endInclusive parameters, as well as the start and end UtcTimeOfDays which itself does the tick adding/subtracting when needed.




Update

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.