Generator-jhipster: Replace ZonedDateTime with LocalDateTime / add LocalDateTime

[kfronc]

Is there any reason, why default DateTime type is ZonedDateTime in JHipster?
In all the application I did I found myself having to replace it. LocalDateTime is the standard type, ZonedDateTime is more specified type which in itself holds LocalDateTime. I don't understand the decision that led to use of ZonedDateTime.

And replacing ZonedDateTime with LocalDateTime is extremely annoying (especially datetime picker on front).

There are uses for both of those types, that's for sure. But storing stuff like birth datetimes, historical events datetimes and stuff like that doesn't really make sense with ZonedDateTime.

I saw one thread #3271 which was closed (I think very much prematurely) without really good reasons. If you don't want to support all the types than use the default and simplest one, which can be converted easily.

In each and every application, where I needed to use DateTime I always wanted it to be LocalDateTime and seriously, converting it is very time consuming.

[jdubois]

Just to be sure: I guess you already see we have LocalDate and ZonedDateTime?
The idea was that, if you want the time, you also probably want the time zone information with it.

As you say, those are all different use cases, so basically it's just us who didn't code the LocalDateTime support, which indeed is a good idea.

Of course there are lots of types we could add, it's just a matter of coding them, and maintaining them, and we just don't have the time to do everything. If you need this one, a contribution from your part would be highly appreciated.

So this is a good type to add, but I'm closing this, for two reasons:

• We are currently working on the AngularJS 2 version of JHipster, so we have frozen all development of new types (or anything else that would change the front end). I've added the "willdolater" tag to this tag for this reason, we'll have a look at it after the AngularJ 2 release. Unless this doesn't change anything in the front end -> correct me if I'm wrong here.
• We just don't have the time to do everything. If you want to do a contribution on this, I'll happily merge it (but be careful with AngularJS 2, have a look at the specific branch we have for it).

[cbornet]

I would never use LocalDatetime to represent a datetime : it doesn't represent an instant on the timeline (no reference to epoch) ! If you want something simpler than ZonedDateTime, using Instant or OffsetDatetime would be better. I have not found a use case where LocalDatetime would be useful but maybe there are...

[cbornet]

I'm revising my judgement here.

LocalDateTime would be useful when you want to represent a local datetime in the future that doesn't change even if the DST rules change (for political reasons for instance. It happens more often than you can think...). It could be for instance for an appointment in the future that is at 08 AM : you probably don't want the local datetime to change to 09 AM if the DST rules change (you'll be late at your meeting).

Normally you could use ZonedDateTime for this as it is an assembly of a LocalDateTime and a ZoneId. But the support of timezone in RDBMS is not an easy thing : some seem to support it (Oracle, DB2), and others don't (even if timestamp with time zone type exists in PostgreSQL, the truely stored value is an UTC timestamp). So for the moment, Hibernate 5 doesn't support storing timezone info for ZonedDateTime and just does a mapping to java.sql.Timestamp.
And we do the same in JHipster : we always map ZonedDateTime to a "UTC timestamp" before storage whether it be SQL/Cassandra/Mongo.

So we have a type to represent a "fix instant on the time-line"/"UTC timestamp" (and Instant or OffsetDateTime would probably be more appropriate for this as this is what they are meant for) and users could have a usage for a "local datetime independant of DST rules" type. And since we can't use ZonedDateTime, LocalDateTime is the answer (note that you will still need to get the timezone associated from another source).

To sum up, I'm all for implementing LocalDateTime and probably also Instant or OffsetDateTime or both and I can do it when Angular 2 is released if OK.
We should probably also document somewhere that ZonedDateTime is converted to UTC and stored without TZ as this is not obvious.

[mrozlukasz]

:+1 For LocalDateTime. In my opinion the referral specification should be https://hibernate.atlassian.net/browse/HHH-8844 People who generate projects with JHipster should be able to express all their intentions.

[cbornet]

@mrozlukasz PR is welcome :smile:

[ghost]

Please provide the support for java.time.LocalTime, java.time.LocalDateTime, java.time.OffsetTime and java.time.OffsetDateTime.

[cbornet]

Again, this is a community project. PR is welcome.

[funder7]

Hi,
I was looking for LocalDateTime / LocalTime implementation, and found this issue, but it's closed.
In my opinion it's a nice to have feature, recently I had to change by hand all the fields where LocalTime is needed. On a large project, this can lead to errors, in case you forget to restore the field back from let's say "AnyType" to LocalTime or whatever type not supported.

Even if LocalTime and LocalDateTime are not storing the Zone information, I'm sure that they're quite used among developers, including me :-)

I see this issue here from long time, I'd like to contribute and integrate this feature in the next month, I've tried to open a pull request, but honestly I never did that, I don't know how it works!
Does it need an open issue to be requested?

[pascalgrimaud]

@f-ricchiuto : yes please, before starting to work on something, first, open an issue and discuss. Explain why you think it's important to have and which are the use cases. Once it's approved by the core team, then you'll be able to start the work

[funder7]

@pascalgrimaud Ok thanks for the explanation, so in order to discuss about a topic, I'll need just to open a new issue?

[pascalgrimaud]

@f-ricchiuto : yes plz, open a new issue for discussing about it.

[funder7]

that's fine. Just I'm a bit busy in these weeks, but as soon as I will encounter the problem again, I will open a new issue!