Property types for LocalDate, LocalDateTime and LocalTime

[ljacqu]

Not sure about this yet, but it may make sense to have out-of-the-box support for LocalDate and LocalDateTime. (And LocalTime?)

To do

• Introduce a PropertyType for the respective types
• Introduce a Property implementation for each new PropertyType

[thepoetdj]

@ljacqu I am new here and I would like to take this up. Can you please assign this to me.

[ljacqu]

hi @thepoetdj, absolutely! If you need any pointers, just shout :)

[thepoetdj]

@ljacqu I was exploring the source and noticed that this can be implemented in a fashion somewhat similar to the NumberType.

I am thinking introducing a TemporalType, and then implementing respective LocalDateProperty / LocalDateTimeProperty / LocalTimeProperty.

Also, should we support ISO format as default or let the user specify the format along with the date/time value?

[ljacqu]

hi @thepoetdj, that sounds like a great plan! I guess it would be nice to be able to specify a format, if that's at all possible, and to offer a few standard implementations as is done in RegexType. For LocalDate, probably we want to have "yyyy-mm-dd", "dd.mm.yyyy" and "mm/dd/yyyy" as constants on your type class (TemporalType or however the types end up). Just my two cents

[thepoetdj]

Apologies for the delay. @ljacqu if you get a chance, can you have a look at the changes I've pushed and share some thoughts on the approach. Thanks.

[ljacqu]

Hi @thepoetdj, this looks fantastic! Matches the style of the code base perfectly and you figured out that the export value should be a String. Also using PropertyAndLeafType is great. 10/10, I'm impressed!

I like that you supported all three formats (yyyy-mm-dd, dd.mm.yyyy and mm/dd/yyyy), I hadn't even thought about that. The date will always be exported in the yyyy-mm-dd format, which I think is OK, since someone wanting a specific format could just override the toExportValue method – so your approach works well.

Just as a hint, your additions with LocalDate (and maybe LocalDateTime?) will be a great addition to LeafValueHandlerImpl#createDefaultLeafTypes, so that LocalDate will also be supported in the bean mapper.

Small impl details:

• I think LocalDate.from(value).toString() equates to value.toString() in TemporalType#toExportValue
• Probably will make sense to have either the TemporalType constructor public or to offer public static methods so that people can define other types, say if they wanted to only support a date with a certain format or implement some Temporal type we won't offer by default (e.g. YearMonth).
  • However, if we open up the type we need to make sure that the export value can be parsed again. So maybe the export value should use the first format it's configured with (just as a spontaneous idea)

[thepoetdj]

Thanks for the comprehensive feedback @ljacqu.

In summary:

• I'll have a look at LeafValueHandlerImpl to add support for TemporalTypes which we will provide as a default.
• Yes, value.toString() is sufficient. It may change however when we make TemporalType constructor public. For export format, we can either:
  • Use the format that matched when converting (although I have doubts on that), or
  • Use the first available supportedFormat provided on initialization (as suggested)