На русском:
https://habr.com/ru/company/otus/blog/567338/
Вот целый абзац о том, почему были выбраны именно такие названия:
Придумывать имена всегда непросто, и этот случай — не исключение. Мы долго обсуждали разные варианты имен, но в итоге приняли имена DateOnly и TimeOnly, так как они соответствуют ряду условий и ограничений:
Они не используют зарезервированные ключевые слова языка .NET. Date было бы идеальным вариантом, но это ключевое слово в языке VB.NET и тип данных, являющийся псевдонимом System.DateTime, поэтому это имя было отвергнуто.
Их легко найти в документации и с помощью IntelliSense, введя их начало — Date или Time. Мы сочли это важным, поскольку множество разработчиков .NET-приложений привыкло к типам DateTime и TimeSpan. В других платформах аналогичная функциональность обозначается префиксами, например Java-классы LocalDate и LocalTime из пакета java.time или же типы PlainDate и PlainTime в готовящемся к выпуску предложении Temporal для JavaScript. Но в этих примерах все типы дат и времени сгруппированы в отдельное пространство имен, в то время как в .NET типы даты и времени находятся в общем пространстве имен System.
Их трудно спутать с существующими возможностями API. В частности, оба типа DateTime и DateTimeOffset имеют свойства с именами Date (возвращает DateTime) и TimeOfDay (возвращает TimeSpan). Мы сочли, что если бы тип назывался TimeOfDay вместо TimeOnly, было бы нелогично, что свойство DateTime.TimeOfDay возвращает тип TimeSpan, а не TimeOfDay. Если бы мы делали все с нуля, мы выбрали бы эти имена в качестве имен свойств и имен типов, которые они возвращают, но такое радикальное изменение сейчас просто невозможно.
Они легко запоминаются и имеют интуитивно понятный смысл. Ведь имена DateOnly и TimeOnly явно говорят о том, что эти типы должны использоваться для указания «только даты» и «только времени». Более того, при их комбинировании образуется тип DateTime, поэтому, давая им такие имена, мы логически связываем их друг с другом.
Круть!
