It's not so much that I am trying to avoid textual representations. It's more a matter of how you expect to use these values. For example, if you want to use these values in arithmetic or comparisons - that defines a new set of requirements. E.g., consider a query like ... where p.birthDay - 1 = ... where birthDay is defined as MonthDay - we need to store the birthDay in such a way that the arithmetic / comparison is viable. That means a few restrictions. IMO it means no CHAR-based storage. It also means the value should be stored as a single DB value (single column). It is a similar discussion we've had on mailing list and elsewhere with regard to timezones e.g. I agree with Dan The about most of these... Not sure why Year should go in a separate issue - this issue is specifically asking for Year support I do agree though that we should split these up. In total I am hearing requests to support:
- Year
- MonthDay
- YearMonth
- ZoneId
- ZoneOffset
Year is super trivial - its just an integer For ZoneId and ZoneOffset, I created HHH-13393 Open MonthDay and YearMonth are not quite so trivial as mentioned above. I dislike the idea of using conversions to/from Date or Instant or ... And I very much dislike the idea of storing these as any form of DATE. For me, it comes back to the capabilities we want to support there as discussed above (arithmetic, etc). I'm ok with just storing the text if we do not think the arithmetic/comparison capabilities are needed. Created HHH-13394 Open to track these. |