> 2. Spec updates JDO-749 "Support for java.time types, and querying using > associated methods" https://issues.apache.org/jira/browse/JDO-749 > > Chapter 14: why are other supported time types not orderable?
No reason, I simply added LocalDateTime, LocalDate, LocalTime where Date was previously mentioned - this could become supported java.time types. But then there are other types not mentioned in that section that are supported as persistable (Locale, Calendar, etc), so why were they excluded?. Same applies in Result Class Requirements section. > Chapter 18: why don't other supported time types not have default JDBC types? Because the default still needs defining. To give an example java.time.YearMonth can be persisted (by DN) as * String * DATE (setting day to 0) * (INT, INT) storing the year and month. > There is special treatment for Local time, date, and date time. Are there > implementation issues? I see no implementation issue, and I also see no "special treatment" (in the spec). Where? > 4. Other issues > > There are several un-accepted changes in the specification noticed during > review of changes in JIRA issues. Do you mean "Track Changes" is ON in the spec docs in SVN? clearly, because the tracked changes in those docs are what has changed since 3.1 (so that it is easier to compile a list of changes when 3.2/4.0 is ever released). Or maybe you mean something else When is there confirmation of what this release is to be called? I'm assuming 3.2, but such a thing should be decided up front when the scope of changes is visible ... which it is. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)