Le mer. 23 janv. 2019 à 10:29, Mark Struberg <strub...@yahoo.de.invalid> a écrit :
> 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 > This is supposed to be in SQL spec but my experience with it is close to yours: sometimes it works, depends the DB :( > > 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. > My understanding is that we don't need to get the same model in a write/read roundtrip but the same instant as well > > > Btw, I would also like to support java.time.Instant. Wdyt? > yes and Zoned flavors > > It is _not_ required by the JPA-2.2 spec, but afaict this is silly. It > should have been. > +1, my understanding of the "not support" is jdbc restriction in types but I can be wrong here > Do we also want to add this to our DBDictionary and support it out of the > box? > If there is a native db type yes, if not let's just bridge to a native type internally? > > 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 > >> > >> > >
