Txs Romain! Found a bit more info.
There is a new Type in Java8 java.sql.Types.TIME_WITH_TIMEZONE even. Seems like a few databases do support timezones in the date, others don't Oracle: TIMESTAMP WITH TIME ZONE -> stores the tst + the timezone in the DB in a bijective way PostgreSQL: TIME WITH TIME ZONE -> always only stores in UTC. No way to regain access to the original TZ information. h2: RECORD_UTC. Stores the UTC, same as with PostgreSQL Btw, even for those databases which support timezones it's actually NOT an offset. Because the offset might change if daylight saving So I wonoder if there is any way to get it 100% right. The question is whether OffsetDateTime is actually more like an Instant then? Because we will loose the TZ. Btw, I would also like to support java.time.Instant. Wdyt? It is _not_ required by the JPA-2.2 spec, but afaict this is silly. It should have been. Do we also want to add this to our DBDictionary and support it out of the box? LieGrue, strub > Am 23.01.2019 um 08:45 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > pg has "with time zone" option like "time with time zone" > now I wonder if the dictionnary shouldn't get the config of the default > timezone and if we dont have a type with tz then we convert in the default > timezone > so if i want to store a CEST time and default is UTC then the next select > will get it in UTC but since it is an OffsetXXX it will be "right". > > wdyt? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 23 janv. 2019 à 08:38, Mark Struberg <strub...@yahoo.de.invalid> a > écrit : > >> The OpenJPA internal 'infrastructure' is now ready. >> >> The problem arises about how to store OffsetTime and OffsetDateTime in the >> DB though. >> >> My first implementation now converts it to the default TZ and uses >> java.sql.Date to store it. >> This results in the correct time being stored to the db, but of course, >> the offset is gone. >> >> Does someone has any ideas/links/knowledge about it? >> Mainly want to target derby/Oracle/PostgreSQL/MySQL/MariaDB/DB2 in the >> first round. >> >> LieGrue, >> strub >> >> >>> Am 22.01.2019 um 03:42 schrieb Maxim Solodovnik <solomax...@gmail.com>: >>> >>> Thanks for that, will try to test LocalDate support in our project later >>> this week :) >>> >>> On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò < >> ilgro...@apache.org> >>> wrote: >>> >>>> On 21/01/19 16:07, Romain Manni-Bucau wrote: >>>>> +1000 to make it part of the dictionary, makes way more sense IMHO >>>> >>>> +1001 then, I also think it's better :-) >>>> >>>> Thanks Mark! >>>> Regards. >>>> >>>>> Le lun. 21 janv. 2019 à 15:53, Mark Struberg <strub...@yahoo.de.invalid >>> >>>> a >>>>> écrit : >>>>> >>>>>> hi folks! >>>>>> Over the last few days I started to implement the Java8 time types >> which >>>>>> are required by the JPA-2.2 spec. >>>>>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime >>>>>> The first 3 are pretty much finished. Will work on the later 2 today.I >>>>>> first started to implement LocalDate as ValueHandler. But some >> databases >>>>>> (postgres, etc) do have native support for those types. So I figured >> it >>>>>> might be better to add support for it directly in the DBDictionary. >> This >>>>>> also improves performance. >>>>>> Wdyt?Any input or ideas how to make it better? >>>>>> >>>>>> LieGrue,strub >>>> >>>> -- >>>> Francesco Chicchiriccò >>>> >>>> Tirasa - Open Source Excellence >>>> http://www.tirasa.net/ >>>> >>>> Member at The Apache Software Foundation >>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail >>>> http://home.apache.org/~ilgrosso/ >>>> >>>> >>> >>> -- >>> WBR >>> Maxim aka solomax >> >>
