LocalDate and LocalDateTime depend on ZonedDateTime

Question

Why are the methods:

public ZonedDateTime atStartOfDay(ZoneId zone) from class LocalDate

and

public ZonedDateTime atZone(ZoneId zone) from class LocalDateTime

adding dependencies to ZonedDateTime?

They look like "util" methods from ZonedDateTime and are in fact creating dependencies from classes (LocalDate and LocalDateTime) that shouldn't know anything about time zones.

Also, there are a lot more "util" methods that could be added to those classes to "help" with time zones.

Is this the best approach in terms of architecture?

Answer 1

While I didn’t design those classes and am no mind reader, here’s my guess. A major design goal of java.time was the fluent API, the possibility of chaining method calls in a way that feels natural. You may do for example

    LocalDate.parse("12/6/2000", DateTimeFormatter.ofPattern("d/M/uuuu"))
            .atStartOfDay(ZoneId.of("Asia/Kolkata"))
            .toInstant()
            .toEpochMilli()

Such method chaining requires that the LocalDate object returned from LocalDate.parse() accepts the call to atStartOfDay. Think how the code would look if instead you would have to use a static method in ZonedDateTIme:

    ZonedDateTime.ofStartOfDay(LocalDate.parse("12/6/2000", DateTimeFormatter.ofPattern("d/M/uuuu")),
                    ZoneId.of("Asia/Kolkata")))
            .toInstant()
            .toEpochMilli()

It’s severely harder to read. Putting the method into an utillity class instead would not help, the code would still be quite similar.

I do get your point: a cost of the fluent API is that LocalDate depends on ZonedDateTime, a dependency that cannot be explained/justified within the domain alone.