If you want something like a birthday, you’re already making assumptions about the beginning and end of that day. Ask a 21-year old from Australia about getting into USA bars on their birthday. It’s a system-specific decision on how to handle those things. Probably more relevant to finance, but the underlying principle is the same: dates without timestamps are ultimately derived from or interpreted with dates with timestamps, and hiding that fact too early in an API (like LocalDate might do) is a bad abstraction.
“Local date” is a useful concept on its own, and it is not at all always derived from an absolute instant of time. Some examples:
1. Date in a file/directory name, which often happens with big data processing. There is no way to tie these dates to some absolute frame of reference without external information, but it is often not really necessary, and there is still a need to work with these values as dates, e.g. compare them or compute offsets.
2. Anything which is tied to the user’s local time frame, e.g. alarms. They simply cannot be tied to some absolute time reference, because they always represent some time wherever the user is located right now. Even birthday is something like this, because for the purposes of celebration, people care about the specific calendar day, not the actual moment of time in whatever absolute time scale there is (at least, most of the people I know think like that!)