The problems with 23:59:59.9999 etc are aliasing and granularity issues, i.e. breaks and overlaps when used as intervals or inequalities, and the consequences may be anything from innocuous (calendar alarms) to catastrophic (financial reporting).

Firstly, users tend to write them as 23:59:59 or even 23:59. When used as a query, this can skip a second or even a minute of data.

Secondly, 00:00:00.0000 can match the first moment of tomorrow, which may also be wrong, and happens readily when timestamped data is imported from systems with per-second granularity.

Finally, these forms constrain any internal representation, which cannot now ever evaluate to 23:59:59.99995 lest we suffer the same category of fault. This'd limit a standard library's timestamp object to a precision of 10μs, which is pretty coarse for many timing needs.

The proper form, that is, the ideal mathematical representation, is an interval with a closed left/lower bound and an open right/upper bound. That's written like

    [00:00:00.0000, 00:00:00.000+1day) or equivalently

    { t | 00:00:00.0000 <= t < 00:00:00.0000+1day }

and can be pronounced "all times from and including midnight onwards, until (but strictly excluding) midnight the next day". These half-open intervals correspond advantageously to the continuously linear assumptions of chronometric time, with two properties of critical relevance: they can be recorded via commonplace machine representations of timestamps; and, they may be compared, subdivided, and concatenated without inadvertent breaks and overlaps. These qualities eliminate most aliasing & granularity concerns.

Some (sadly not all) programming languages have such a construct available in their standard library.

I think there's a paper by Lamport recommending this form, although I couldn't find it in a quick rummage through the archives.