The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.
It depends on the application and what the customer need is.
My son’s friend in school was born on February 29. We could go through the time pedantry and claim that she is 1 year old (she is 6), or pick an arbritrary moment in time (say March 1, except for leap year) and get on with the party.
If you’re plotting a satellite course, the details matter, but many, if not most use cases require consistency over precision.
If you are dealing with physics, like a satellite course, "wall time clock" is irrelevant. Wall time clock is a human construct that is ambiguous in many edge cases, dependent on position and local politics.
Indeed, your son's friend's age is an ambiguous notion, Hence the need of a more precise contract than a simple date.
All of calendaring is essentially conditions, though. Your point about this being a separate concept still stands.
It's unfortunate how few libraries exist to handle abstract datetime constructs, and how frequently programming environments screw this up. The only one I know of that doesn't mince concepts is Java 8 Time [1], where points-on-timeline timestamps are clearly separate from human-centric calendrical concepts like Time-of-Day (LocalTime) and Month-Day without a year, so there's an appropriate datatype to model lots of common use-cases of date math.
The tricky thing to realize is that this is not a datetime. This is more of a contract/condition saying "when localtime will be at this value" or better yet "when localtime will have exceeded this value for the first time" because you know someone will put a date on a leap second or missing DST hour at one point.