In Java,
Instant represents a point in time, encoded as date and time in
UTC.LocalDateTime represents a point in time, encoded as date and time in the JVM local timezone.Why then does LocalDateTime.ofInstant() require a ZoneId as a second argument ?
This makes LocalDateTime not only confusing and potentially incorrect, but also makes it identical to ZonedDateTime; because the timezone of LocalDateTime can be any timezone just like ZonedDateTime.
And
LocalDateTimerepresents a point in time, encoded as date and time in the JVM local timezone.
No, that's not true. Regardless of the "encoded as" part (which I highly doubt, but which I don't have significant knowledge of to disprove), a LocalDateTime does not represent a point in time. It represents a local date/time, without reference to a specific time zone. Any given LocalDateTime occurs at different points in time in different time zones.
Currently the local date and time in the Europe/London time zone is 2023-01-26T08:50. The same point in time in (say) America/New_York would result in a different LocalDateTime. Whereas in America/New_York, the LocalDateTime of 2023-01-26T08:50 occurs as a different point in time.
For some LocalDateTime / time zone combinations, there may be zero or two corresponding points in time - for example, the LocalDateTime 2022-11-06T01:30 will occur in America/New_York at both 2022-11-06 05:30:00Z and 2022-11-06 06:30:00Z.
Hopefully this is sufficient evidence that a LocalDateTime really isn't a point in time...