Hello everyone;
For Turkish : LocalDateTime kullanımı ile ilgili sorunlar ve çözümler
Although it seems logical to choose LocalDateTime for time type objects in Java projects, sometimes this choice can cause many problems.In fact, I will explain whether or not to use it according to the selected scenario, and if so, the problems it will cause and the solutions to these problems in this article.
What is the problem with the using LocalDateTime?
First of all, the LocalDateTime object is “local”. It does not have any time zone info. There is no explicit time zone. Therefore, the code we write actually depends on the environment, i.e. the time zone we are connected to.But this environment or timeframe cannot be trusted.Server, client and database may be connected to different “time zones”.Even server, client and database can have different “time zone” values at different times. So it can change.
Let’s imagine a scenario like this: Let’s have a server in a data center in Turkey. Then let’s imagine that we move this server to the UK.What happened first? Time zone changed.The environment, the locality has changed. Domain name is the same, application is the same but locality has changed.For the developer writing code or for the users, everything may look the same. But for the server, since the locality has changed, the default “time zone” has changed and a different time zone has been switched.This is where it will cause many problems.
When we think in terms of the client, when we send a request to an API, if there is information containing LocalDateTime in the response, this value may be interpreted differently by the client.In this section, this “time zone” value can be specified in some API documentation. It can be interpreted according to this “time zone” information specified on the user side. However, this information is usually not in the API documentation. As a result, it is inevitable to change information containing LocalDateTime in the API.
Another case is when 2 different date values are compared. Since the LocalDateTime value depends on locality, can we say with certainty that 2 different date values are the same or different? Comparing 2 different date values without specifying a “time zone” value would be illogical.
Even if we are sure that 2 different date values are in the same time zone, we cannot actually compare them. Because local time is not “linear”. And what does that mean? There is a concept called DST. That is, the “Daylight Saving Time” period. (https://en.wikipedia.org/wiki/Daylight_saving_time). So setting clocks forward by one hour in spring and setting it back also by one hour in autumn to bring more daylight to working hours.This is what we mean by “linear” non-linearity.This has been practiced in many countries.(Not practiced in our country(Turkey) in recent years)
If we go through an example, in autumn (let’s say the 23rd of the month in September), the time zone is EEST (Eastern European Summer Time). Local time is 02:55.This time corresponds to 23:55 UTC (11:55 pm).After 5 minutes, at 03:00, the clocks will be turned back by 1 hour.After 10 minutes local time will be 02:05 (UTC 00:05, UTC+2).After 50 minutes it will be 02:55 again.The clock will be duplicated. In other words, time will lose its “uniq” feature.In such a case, the feature of comparing or sorting 2 time data will be faulty.This situation causes errors in interoperability, scheduled meeting processes, product procurement, historical history of transactions, process reporting within a certain time period, etc.In such cases, if the time zone is unknown, we may see different data in the same time period.
using ZonedDateTime?
Can we solve this problem using ZonedDateTime?
First of all, we can think that ZonedDateTime is intended to solve this problem since it contains a time zone. If there is a ZonedDateTime object in the response from the API, the user can clearly see the time zone information here.The ZonedDateTime object contains timestamp and time zone information. This information is not tied to a “local” environment.However, ZonedDateTime is still not linear. The time zone remains the same, but the deviation with respect to UTC changes.
For example, going back to our first example, before the time difference adjustment (02:55) there is a 3-hour time difference with local time UTC.(offset). After 10 minutes, local time is set back 1 hour. (02:05) There is a 2-hour difference according to UTC, but at the local time point, the time reaches the same value again (02:55) after 50 minutes. Naturally, duplication occurs at the time point.Naturally, the problems of comparing two different times arise again. The timezone does not change in ZonedDateTime, but our problem is still not solved.
using OffsetDateTime?
Can we solve this problem using OffsetDateTime?
OffsetDateTime also indicates the deviation from UTC along with the time. This actually leads to linearity in time.It almost makes it safer in many situations. We can compare the two times with confidence.We can also provide this information to the client securely during API calls.It may seem to solve our problems for now. OffsetDateTime is primarily abstract and not tied to any real time period. Shows time and deviation from UTC.
Determination of time and time zones is also based on geographical and political foundations.Depending on political decisions, decisions can be made for different time periods in a country or in certain regions of the country.The OffsetDateTime value corresponds to a time that is not dependent on an actual time zone, country, or locale. That’s pretty abstract.If we consider our country, Turkey corresponds to UTC+3. Winter time corresponds to UTC+2 and summer time corresponds to UTC+3.However, in recent years, the summer and winter time shifting has been abandoned by the government, so UTC+3 has been switched to all times of the year.Maybe after a few years, this decision will be abandoned and shifting of winter time and summer time will be returned.When we think about it from this perspective, our variable will be wrong.
From other perspectives, it solves our problems with LocalDateTime and ZonedDateTime, but it still doesn’t give us a real time zone.
using Instant?
Instant is actually a ZonedDateTime object. The difference is that it has a locked UTC time zone.UTC time zone actually saves us from all problems caused by daylight saving time.The basic idea of Instant: When an event occurs, it actually occurs in all time periods.Instant represents a moment in time (moment in UTC) and is independent of time zone.It is the total number of nanoseconds since 1970 UTC.Compatible with Instant OffsetDateTime and ZonedDateTime at the serialization and database level. All data of this type comply with ISO-8601 serialization/deserialization standards.
As a result, Instant solves all problems with LocalDateTime. It is not dependent on locality, it performs serialization with UTC information in API usage.It has linearity in time. It is independent of conditions such as daylight saving time. It is reliable in these respects.
After all, that doesn’t mean use Instant for everything. Depending on your scenario, using Instant may not be appropriate.
ZonedDateTime usage scenarios
If there are APIs that legacy app and these APIs are integrated with other services, you can use ZonedDateTime to ensure compatibility.If there are time zone sensitive schedule/job services, you can use them. In another example scenario, if you are running an e-commerce campaign within a certain time period, the time zone is important for you.If you are making a discount between 10.00 and 16.00 in a region, you do not need to think about things like daylight hours or UTC.If you have tasks that depend on a time period depending on your process, we can use it at this point, such as sending e-mails, calendar transactions, etc.
LocalDateTime usage scenarios
When we want to send a notification to the user during the day (10:00), we can send it according to the user’s local time.When we look at it from this perspective, users in each different region will receive this notification at different moments in time. This notification is sent according to the user’s local time (each at 10:00 in their local time).We will convert this LocalDateTime value as ZonedDateTime as time-zone in a distributed system.In another scenario, when the user wants to report information and data about herself, the time-zone value or UTC value is not important for the user. With time, we can display information as local time.
I hope it was useful for you too. Thank you for reading.
