Question

Joda-Time library includes different datetime classes

DateTime – Immutable replacement
for JDK Calendar
DateMidnight
– Immutable class representing a date where the time is forced to
midnight
LocalDateTime –
Immutable class representing a local
date and time (no time zone)

I’m wondering how are you using these classes in your Layered Applications.

I see advantages in having almost all the Interfaces using LocalDateTime (at the Service Layer at least) so that my Application doesn’t have to manage Timezones and can safely assume Times always in UTC. My app could then use DateTime to manage Timezones at the very beginning of the Execution’s Flow.

I’m also wondering in which scenario can DateMidnight be useful.

Answer 1

I see advantages in having almost all
the Interfaces using LocalDateTime (at
the Service Layer at least) so that my
Application doesn’t have to manage
Timezones and can safely assume Times always in UTC.

I’m not sure I understand your line of thinking here. LocalDateTime and DateTime represent two quite different concepts. It’s not the case that a LocalDateTime has some implicit UTC timezone: it actually has no timezone (internally it may be represented as a DateTime with UTC timezone, but it’s just an implementation detail, it does not matter to the programmer who uses it).

You can see in the API docs that, while a DateTime is an "Instant" (a point in the world time line, a physical concept), a LocalDateTime is NOT such a thing. The LocalDateTime is actually a Partial, (a "civil" concept), in a different class hierarchy. The class names might -unfortunately- make you think that LocalDateTime is some specialization of DateTime: well, it isn’t.

A LocalDateTime should be regarded as a pair {Date (Y/M/D) ; Time (hh:mm:ss.msec)}, a bunch of numbers which corresponds to the "civil" standard representation of time-related data. If we are given a LocalDateTime, we cannot convert it directly to a DateTime, we need to specify a timezone; and that conversion takes us to another kind of entity. (An analogy: Strings and byte streams in Java: to convert between them, you must specify a charset encoding, because they are conceptually different things)

When to use one or the other in the application… it’s sometimes arguable, but frequently it’s clear enough once the Jodatime concepts are understood. And IMO is not much related to "layers", perhaps more to use cases or scenarios.

A non-trivial -borderline- example: You work at Google, programming the Calendar. You must let the user manage (add, see, modify) an event which includes a date-time (lets ignore recurrent events), say "I have an appointment with my doctor on 2019-July-3 at 10:00 am". What is the time-date entity to use in the software layer (for this usecase)? I’d say: a LocalDateTime. Because the user is not really dealing with a physical point in time, but with a civil time: the date and time that displays the clock in his wrist or in his home. He does not even think of timezones (lets ignore the special case of a user who is traveling around the world…) Then, in the business and presentation layer, a LocalDateTime seems the right entity.

But suppose that you must also code a different scenario: a reminder. When the Google internal scheduler detects that the event stored by the user is N minutes in the future from now, it must send him a reminder. Here, "N minutes from now" is a totally "physical" concept of time, so here the "business layer" would deal with a DateTime. There are several alternatives, for example: the event was stored in the DB as a LocalDateTime (ie. just time and date without timezone – one frequently uses a UTC timestamp to represent that, but this is an implementation detail). In this scenario (only in this), we must load it as a DateTime, we convert it using a Timezone, probably from the user’s profile.