Curious about the design choice - is there any authoritative source about the design decision to not have a simple converter for LocalDate -> Date and viceversa baked into the LocalDate object?
I'm fed up of moving these objects around with the completely clunky
java.util.Date.from(dateToConvert.atStartOfDay()
.atZone(ZoneId.systemDefault())
.toInstant());
and the other one,
dateToConvert.toInstant()
.atZone(ZoneId.systemDefault())
.toLocalDateTime();
And while i know I cannot have date.toLocalDate(nullable ZoneId), it would at least be of some use to know why (if only so I never ever justify a decision using the same logic).
You might as well ask why there is no built in conversion method to turn a File object into an integer: The 2 types are almost entirely unrelated.
But, I hear you say, hold the phone, rzwitserloot! What the heck are you on about? Date and LocalDate are unrelated???
Yes, they are.
Because java.util.Date is a silly name. That's NOT what j.u.Date represents; that's why all the date-related methods in this object are deprecated. Once you see that a class named Date has a method called getHours that should hopefully be a good indication that whomever named it was, let's just go with 'having an off day'. That aint no date.
j.u.Date represents 'a moment in time'. It is the exact equivalent to java.time.Instant. Its internal storage is a single long representing epoch-millis and nothing more.
This has almost no relationship whatsoever with LocalDate.
Yes, MANY systems use a j.u.Date object as a way to represent the same notion that LocalDate is trying to represent, but that is because those systems messed up, and are using an entirely inappropriate type for it. They may be excused; they just fell for the same trap you did: They got thrown off by the name of this class.
Perhaps one might argue: Okay, but, hey, we live in this world and not a fairytale one, so given that so many times 'I need to convert this j.u.Date to LocalDate' comes up, it should be easier, right? Well, enabling bad behaviour just because it is common – let's just say the word is out on whether that's a good idea. Also, that job rather fundamentally is very very tricky. How do we do this conversion? Should I take the moment in time as represented by the j.u.Date object, check out what the actual calendar date is in the current system default locale (as in, go to where the server is. Now go out the building. Find a person. Ask them: What date is it right now? What do they answer?) – or should they go UTC locale? (Go to Greenwich and ask there. Unless it is summer, then ask: What date was it one hour ago?).
The answers obviously won't be the same in many cases, and yet neither strategy is obviously superior to the other. Thus, making such a convenience method is just going to cause epic reams of confusion. You're missing a crucial bit of info, if not more – the job of converting a j.u.Date to a LocalDate cannot be done without further context unless you're willing to just toss a coin on every missing bit of info you have. You might as well invoke a Random instance's .nextInt(365) to figure it out.