Why does LocalDateTime.ofInstant() requires ZoneId

Question

In Java,

If Instant represents a point in time, encoded as date and time in UTC.
And LocalDateTime represents a point in time, encoded as date and time in the JVM local timezone.

Why then does LocalDateTime.ofInstant() require a ZoneId as a second argument ?

This makes LocalDateTime not only confusing and potentially incorrect, but also makes it identical to ZonedDateTime; because the timezone of LocalDateTime can be any timezone just like ZonedDateTime.

There really isn’t much good use for `LocalDateTime`. I think I have always preferred `ZonedDateTime` because it makes time zone explicit, contrary to `LocalDateTime`. For one case where you *do* need a `LocalDateTime` see [Storing appointments in a SQL database such as Postgres for use with java.time framework](https://stackoverflow.com/questions/64545555/storing-appointments-in-a-sql-database-such-as-postgres-for-use-with-java-time-f). — Ole V.V., Jan 26 '23 at 09:21

score 9 · Accepted Answer · answered Jan 26 '23 at 08:50

And LocalDateTime represents a point in time, encoded as date and time in the JVM local timezone.

No, that's not true. Regardless of the "encoded as" part (which I highly doubt, but which I don't have significant knowledge of to disprove), a LocalDateTime does not represent a point in time. It represents a local date/time, without reference to a specific time zone. Any given LocalDateTime occurs at different points in time in different time zones.

Currently the local date and time in the Europe/London time zone is 2023-01-26T08:50. The same point in time in (say) America/New_York would result in a different LocalDateTime. Whereas in America/New_York, the LocalDateTime of 2023-01-26T08:50 occurs as a different point in time.

For some LocalDateTime / time zone combinations, there may be zero or two corresponding points in time - for example, the LocalDateTime 2022-11-06T01:30 will occur in America/New_York at both 2022-11-06 05:30:00Z and 2022-11-06 06:30:00Z.

Hopefully this is sufficient evidence that a LocalDateTime really isn't a point in time...

One may add that the JVM default time zone can be changed on runtime, which would under the OP’s interpretation have caused the `LocalDateTime` object to refer to a different point in time. Of course this is not the intended interpretation. — Ole V.V., Jan 26 '23 at 12:01

score 5 · Answer 2 · answered Jan 26 '23 at 08:51

A LocalDateTime represents a date and time without time zone information. It is used to represent "local time" (as an example for me, right now the local time is 2023-01-26 09:50). An Instant is always at UTC (example, the time right now is 2023-01-26 08:50 UTC). To transform between an Instant and what the observer considers to be local time, you need to know the ZoneId of the location of the observer (e.g. for me Europe/Amsterdam), otherwise you cannot derive a local time.

And to be clear, a LocalDateTime does not represent a point in time (that is what Instant is for). To expand my example, for me the local time 2023-01-26 09:50 is now past, while for Jon Skeet (in Europe/London), that local time will happen in slightly less than an hour).

score 1 · Answer 3 · edited Jan 26 '23 at 08:52

1

.ofInstant() is there to specify the instant and timezone.

If you don't want to specify the time zone and instant you can use .now() wich will use the local date and time.

If you want to specify the instant but not the ZoneId you can use ZomeId.systemDefault().

edited Jan 26 '23 at 08:52

Mark Rotteveel

100,966
191
140
197

answered Jan 26 '23 at 08:51

Daxelarne

172
11

score 1 · Answer 4 · answered Jan 26 '23 at 09:21

An Instant is independent from time zones or offsets, but a LocalDateTime is not. Although it does not have a ZoneId or ZoneOffset, it's values are partially based on the offset the specific zone currently has.

Here's a code example with different zones that lead to different values of the very same Instant:

public static void main(String[] args) throws DateTimeParseException {
    // example instant (see output)
    var instant = Instant.now();
    // get the instant with different time zones
    var ldtBerlin = LocalDateTime.ofInstant(instant, ZoneId.of("Europe/Berlin"));
    var ldtCanberra = LocalDateTime.ofInstant(instant, ZoneId.of("Australia/Canberra"));
    var ldtKolkata = LocalDateTime.ofInstant(instant, ZoneId.of("Asia/Kolkata"));
    var ldtLA = LocalDateTime.ofInstant(instant, ZoneId.of("America/Los_Angeles"));
    // print all the results
    System.out.println("Instant " + instant.toEpochMilli() + " in different zones:");
    System.out.println(ldtBerlin + " (Berlin)");
    System.out.println(ldtCanberra + " (Canberra)");
    System.out.println(ldtKolkata + " (Kolkata)");
    System.out.println(ldtLA + " (Los Angeles)");
}

Output:

Instant 1674724841016 in different zones:
2023-01-26T10:20:41.016228 (Berlin)
2023-01-26T20:20:41.016228 (Canberra)
2023-01-26T14:50:41.016228 (Kolkata)
2023-01-26T01:20:41.016228 (Los Angeles)

View the different values, those are the local dates and times of the zones, but a LocalDateTime does not have any! You can use other objects, like ZonedDateTime (has zone and offset) and OffsetDateTime (has offset). Both of them have a method toLocalDateTime(), in case you need a LocalDateTime later on…

Why does LocalDateTime.ofInstant() requires ZoneId

4 Answers4