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.
LocalDate is an immutable datetime class representing a date without a time zone. LocalDate implements the ReadablePartial interface. To do this, the interface methods focus on the key fields - Year, MonthOfYear and DayOfMonth. However, all date fields may in fact be queried.
A Datetime is instead a physical concept (an instant of time), which in addition has a Timezone, and hence, it can be expressed in day/month/year. a LocalDateTime is just a bunch of numbers (day, month, year, hour, minute...) that represent a civil (not a physic) concept.
So the short answer to your question is: YES (deprecated).
A date without a time-zone in the ISO-8601 calendar system, such as 2007-12-03 . LocalDate is an immutable date-time object that represents a date, often viewed as year-month-day.
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 a implementation detail, it does not matter to the programmer who uses it).
You can see in the API docs that, while a DateTime
is a "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 classes 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 we 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 is 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 appointement 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 bussiness 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 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With