A few things:

• The maximum value that a DateTime in C# can represent is 9999-12-31 23:59:59.9999999. In SQL Server, this corresponds to a datetime2, which has the same maximum value.

• The time type in SQL Server also has a maximum value of 23:59:59.9999999 (though note that a C# TimeSpan can be much larger because it primarily represents duration instead of time of day).

• If you are storing just a time range using the time type, you'll need that 23:59:59.9999999 value for the end of the day. You can get this quickly in C# with DateTime.MaxValue.TimeOfDay. Indeed it will be one tick less than a true 24:00.

• There are 7 decimals of nines because that is the precision offered by the data type. If you choose a lower precision, there is some small (but not impossible) chance that a given value could fall after it. Thus when you use this technique, always align the nines with the full precision of the data type. (Don't just subtract one second or one millisecond.)

• When calculating the difference of a datetime range such as 2020-01-01 00:00 to 2020-01-01 01:00, one can simply subtract the two values to get the result (1 hour in this case). However, when using 23:59:59.99999999, one has to account for the missing tick. This can get messy, and such there is a significant advantage to using 00:00 instead.

• As you pointed out, when displaying 23:59:59.9999999 to an end user, you may have to write your own logic to format it as 24:00 or as "end of day", etc.

• When comparing datetime ranges, you'll want to use a different operator for the end comparison:

  • If you use 23:59:59.9999999, use a fully-inclusive range comparison: a <= now && b >= now
  • If you use 00:00, use a half-open range comparison - inclusive at the start, exclusive at the end: a <= now && b > now

• When comparing time-only ranges (i.e. timspan types), the same logic applies, but one also has to consider time ranges that span over midnight:

  • If you use 23:59:59.9999999:

    if (a < b)
        result = a <= now && b >= now;
    else
        result = a <= now || b >= now;
    

  • If you use 00:00:

    if (a < b)
        result = a <= now && b > now;
    else
        result = a <= now || b > now;
    

In summary, it is generally simpler to work with 00:00 values instead of 23:59:59.9999999 values, and thus you should prefer 00:00. If you find the need to use 23:59:59.9999999, you should be aware of the coding changes required.

programmatically speaking, you can do both. the only difference between them (in code) is this :

 // using 00:00:00 will require you to add 1 day to the end date in order to count as full day
 if(time >= "2019-12-03 00:00:00" && time < "2019-12-04 00:00:00")

//using 23:59:59 will not require you to add 1 day to the end date.
 if(time >= "2019-12-03 00:00:00" && time <= "2019-12-03 23:59:59")

so, basically, if you use 23:59:59 there is a one second off the grid, if any record has been stored in this second, it'll not be included in the results. while the second one will include it.

Which one to use ? surely the 00:00:00 if you want to be more precise, however, I've not seen any difference in the results in my projects as I've used both of them in different projects. But I'm sure there are some projects needs to include every micro second as this microsecond could change the result's curve (such as analytics or deep learning ..etc).

In SQL Server, don't save the time as string, save it with the correct datatype (DateTime, TimeSpan ..etc). SQL Server will reads the time perfectly fine when you pass a correspond time datatype from your application.

It depends on perspective:

var xx = DateTime.MaxValue.ToString("HH:mm:ss.fffffff");
var xy = DateTime.MinValue.ToString("HH:mm:ss.fffffff");

Gives

23:59:59.9999999

00:00:00.0000000

So, one is the end of the day and the other is the beginning of the day.

There's an interesting novel called 'The time between midnight'

DateTime.MaxValue is exactly that - the maximum value that DateTime can represent; that is to say, the 'last' point in a day. Conversely, the .Date property makes use of 00:00:00 by default, as it has no notion of time (unless specified).

If you have an event that occurs at exactly midnight, I would recommend storing it as 00:00:00, as the event occurs at midnight, and you want to accurately represent that.

Ultimately, it really depends on your desired use case as to which one you want to use. Do you want to state that the event occurs on day 1's evening, or day 2's beginning? That is what it boils down to, although in the vast majority of cases such a delineation makes no difference. In this case you would want to opt for both the accuracy and 'ease' of 00:00:00.