-
We should use new datetime API from Java8 instead (`LocalDateTime`).
Depends on:
- [ ] #930
- [ ] #931
- [ ] #933
- [ ] #1032
- [ ] #1033
- [ ] #1622
-
JPA 2.2 defined that a subset of the (then) new JSR 310 date/time types were to be mapped automatically by the JPA implementation.
Unfortunately, the Instant type wasn't among those types being spe…
-
This spec looks like it could be a useful idea, but I'd like to add some thoughts:
Firstly, in JSR-310 (Java's new date-time spec of which I'm the primary author), almost all the types have a MIN a…
-
Java 8 has come and already almost gone, java.time (JSR-310) is now part of JDK and the recommended datetime API that is meant to replace old and clunky java.util.time in new projects (since they can'…
-
This idea has been around for a while (e.g. https://github.com/jOOQ/jOOQ/issues/650) as it is rather difficult to:
- predict jOOQ's current data type registry behaviour
- change this behaviour
…
-
...which mangles data while inserting to database and reading back.
### Symptoms
Saving times to database, changing system time zone and reading data back produces different results from origina…
-
The joda bits are currently stored in the oaipmh extension as this is the only extensions using it. Let's keep in mind that we could create a support extension or a quarkiverse one when a second proje…
-
Bare SimpleDateFormat can parse non standard AM/PM with **DateFormatSymbols.setAmPmStrings** but I cannot find similar feature in JodaTime.
For example in my case AM is "A.M.".
-
JAXB spec should be updated to support new JDK8 Date/Time apis
-
These interfaces have some problems.
1. Values are converted to Java objects and some conversions are slow, buggy and may loss some information. `TIME`, `DATE`, and `TIMESTAMP` are especially affec…