-2

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?

fidudidu
  • 399
  • 3
  • 10
  • 2
    The most important module granularity in Java is the package, and these three are all in `java.time`, so it does not seem a big issue. – Thilo Oct 08 '19 at 08:50
  • When you change the interfaces in the future let me know if the package granularity will help you that much. – fidudidu Oct 08 '19 at 08:51
  • So it's an util method (which knows how to return an object from which a LocalDate knows nothing about).In the future, if you change or even remove the ZonedDateTime you will impact a class that has nothing to know about it... – fidudidu Oct 08 '19 at 09:51

1 Answers1

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.

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161
  • Thank you your answer. I'm sorry for the -2 that this question has fallen into but it's not my fault. I've been experiencing that people don't like good questions and also (even worse) they don't understand it when they rate it. Answering to you, it is precisely what you say, the ZonedDateTime should be the start point to avoid the dependency. Thanks once again. – fidudidu Oct 08 '19 at 14:56