Compatibility and convention have a value in itself.
But you are right - hey are not the most important thing in itself.
If somebody finds names that are clearly better - I am all for it.
But at the moment the suggestions are to just drop the prefix - which does not improve the names very much.
Is it stable for using in production ?
How will it deal with the updates in time zone database?
I wouldn’t say so, considering that the version is 0.1. If you brave enough you can try — the operations provided are well-tested, but expect API changes in the future.
We rely on the time zone database of the underlying platform, but we have a feature in mind that would allow using rules from an embedded timezone database that could be updated separately.
Please at least allow the machine’s tz database to be used as an option.
One of my major headaches a while back was a Java application running on an old OS that couldn’t run the last few Java versions. The (physical) server was in a remote data centre, and there were no opportunities to upgrade it for many months. We updated the machine’s own tz database, but Java bundles its own, which there was no safe way to update. By then it was years out of date, and didn’t know about permanent summer time changes in some countries — you may be able to imagine some of the hilarious consequences of an app spending an hour each day believing that some financial markets were open when they were actually closed, and another hour vice versa…
For now you could use javas timezone updater.
Anyways I guess if that any system that is able to use an externally embedded timezone database will also be able to read from the machine’s tz db.
If the Timezone Updater had been available back then, it would have saved us an awful lot of pain! But even now it is, I still think being able to use the machine’s tz DB would be a useful option.
Excited to see this!
Regarding possibly different implementations for Android - I don’t think this is necessary. Android’s L8 toolchain will backport java.time.* usages just fine. It may make it difficult to update timezone data manually after a certain point though.
Slight plug, but @gabrielittner and I maintain a library for timezone management that works via Java’s system property locator API - GitHub - ZacSweers/ticktock: A timezone data management library for the JVM and Android targeting java.time APIs in Java 8+. This is obviously married to Java’s implementation though, but making something universal may require different solutions.
I wouldn’t drop it. “LocalDateTime” is accurate and precise. LocalDateTime is relative to the locale of the observer rather than having a specified time zone (ZonedDateTime). The semantics are very specific. For example, expressing “noon on March 5th, wherever you are” …is done with a LocalDateTime. Having had to work with calendars and temporal units often, I strongly vote against this. If I see “DateTime” the first thing I think is “local (relative) or zoned?” …and no, this isn’t a Java thing. I spend most of my time in other languages.
I agree that the LocalDateTime class is important, but I am not sure whether that’s the best name it could have been given. Even “GlobalDateTime” might have been a better choice.
I agree that “LocalDateTime” is a better name than “DateTime” as it provokes more thinking and prevents false thoughtless assumptions. For the same reason “GlobalDateTime” might have been an even better name.
GlobalDateTime implies UTC/GMT. LocalDateTime isn’t global. It’s relative to the time zone of the observer. It is the local date time. If you want a universal global date time you would use ZonedDateTime with Z (UTC).
The “local” terminology for date/time relative to the observer’s time zone is a de facto standard. For example, .NET’s DateTime has a Kind property that is set to “Local” to express the same thing. The other options are “UTC” and “Unspecified”. It has a DateTimeOffset to deal with “all others”. While most of the .NET libraries have well designed APIs, DateTime is a bit convoluted. Java’s original Date and Calendar were worse. It’s hard to get right. The new(ish) java.time API is, in my opinion, expertly written by subject matter experts. LocalDateTime is much clearer than .NET’s DateTime with a “Kind” property set to “Local”.
The name LocalDateTime seems odd at first, but if you are working on something like a calendar app the terminology starts to make sense. There is a lot of subtilty in date time APIs.
That does not mean that “GlobalDateTime” has been a good name for what it currently stands for.
Describing it like that can cause misunderstandings. LocalDateTime does not represent a datetime on the timeline. In order interprete it on a timeline, the timezone needs to be provided, which can be the local timezone or any other timezone. If we are exchanging a LocalDateTime it can even mean both the datetime at your location and the datetime at my location.
Exactly, and that is what I am talking about. The first impression of “LocalDateTime” provokes false assumptions. My first impression about “GlobalDateTime” would be no idea whatsoever, so I would better read its documentation before making false assumptions.
I agree though, that it is best to stick to conventions and keep it consistent.
I agree. That is what I mean by “LocalDateTime is generally relative to the observer (or to be strictly accurate, the zone context that is assumed).” A reasonable analogy is relative versus absolute URLs. LocalDateTime is relative and ZonedDateTime is absolute. When I see 2020/08/10T11:00:00 it means something different in UTC time for me in Japan than it does for you in Iceland. It is relative to my locale. When we see 2020/08/10T11:00:00Z (ZonedDateTime for UTC), it means the same thing. It is not local. It is absolute (unless the zone rules change) because it is zoned and can be compared.
It should be noted that this isn’t new territory. The term “Local” to describe a DateTime without a zone is used by many libraries, including Java and .NET. .NET uses a DateTime .Kind property, which can be set to “Local”. The semantics are identical. The term “local time” is in common use, and is utilized by airports and government agencies.
I think you misunderstand what these institutions mean with “local time”. They are absolute times: location (= time zone) + time. So in this (bogus) example, you still know exactly what times you will depart and arrive: departure from Amsterdam 15:00 local time and arrival at new York 15:00 local time.
Together with this:
I would say that a better name for LocalDateTime is RelativeDateTime. This makes it clear that you cannot know the exact time unless you have more information. What information? That will be in the documentation: the time zone or offset.
Just to add another suggestion, I have always referred to that as a WallclockTime.
I.e. it’s the time that you can see on a clock. It’s the concept of 14:24 rather than a specific point in time (which would be a Timestamp).
I think you misunderstand what these institutions mean with “local time”.
I assure you, I do not 
Local time is relative and assumes a you have context for the zone. Zoned time is time with a zone specified. That’s it.
I would say that a better name for
LocalDateTimeisRelativeDateTime. This makes it clear that you cannot know the exact time unless you have more information. What information? That will be in the documentation: the time zone or offset.
I agree that RelativeDateTime also makes sense. @Loke’s WallclockDateTime is also clear, but usually in these cases you use precedence unless you have a good reason not to. There is a lot of precedence for calling it local: Java, .NET, etc.
I suppose you could make an argument for removing “Local” and having just DateTime and ZonedDateTime, but Koltin’s designers have stated that they favor clarity over “saving keystrokes”.