>> As far as I know there wasn't any specific time-related problem with
the org.postgresql:postrgresql driver. I'm not sure we run tests against
pgjdbc, that might be something to consider.
> Please do run your tests against that.
My bad, we do run our tests against that. I confused it with
Dave Cramer
On Mon, 13 Jan 2020 at 11:10, Yoann Rodiere wrote:
> Hi,
>
> As far as I know there wasn't any specific time-related problem with the
> org.postgresql:postrgresql driver. I'm not sure we run tests against
> pgjdbc, that might be something to consider.
>
Please do run your tests
Hi,
As far as I know there wasn't any specific time-related problem with the
org.postgresql:postrgresql driver. I'm not sure we run tests against
pgjdbc, that might be something to consider.
The problems were mainly with MariaDB/MySQL/Sybase drivers, and we upgraded
our dependencies since then,
Hi Steve,
I'm not sure there is a better way to store the data in the database. Doing
any kind of date/time math in anything else but UTC seems fraught with
danger.
See below as to how we handle Java 8 types.
Hi Dave.
Same - I was swamped with stuff at the end of last week.
Yes, from what I was reading postgres is a bit strange in storing temporal
values. Not unique to postgres - many databases do interesting things.
I'm curious how the driver handles binding Java 8 types directly. The JDBC
spec
Sorry Yoann, it was a crazy week and I missed this reply somehow...
Yes, you did an awesome job with setting up tests. We will obviously make
sure those continue to work as we move forward.
I did mention in the original email (I think anyway, I meant to) that there
seemed to be a problem in
Hi,
As one of the maintainers of the postgres jdbc driver I am interested in
this discussion.
Postgres only stores date/times in UTC. Everything else is a translation.
The driver uses the client's timezone for all dates/times (for better or
worse) If there is anything I can do to help make things
Ok, just wanted to make sure I didn't miss anything and understand the
reasoning for your preference :)
Am 09.01.2020 um 13:06 schrieb Steve Ebersole:
> Well, again, this is configurable. If you don't want to use it, don't ;)
>
> On Thu, Jan 9, 2020 at 1:28 AM Christian Beikov
>
Well, again, this is configurable. If you don't want to use it, don't ;)
On Thu, Jan 9, 2020 at 1:28 AM Christian Beikov
wrote:
> Am 08.01.2020 um 20:21 schrieb Steve Ebersole:
>
> On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>>
>> This is about JPA
Am 08.01.2020 um 20:21 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
>
> This is about JPA Criteria whereas I was referring to how a
> literal in
> HQL ends up in the SQL. I agree that with JPA Criteria things
On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov
wrote:
>
> This is about JPA Criteria whereas I was referring to how a literal in
> HQL ends up in the SQL. I agree that with JPA Criteria things are
> different as the API for parameters in queries is not very neat. A flag
> for controlling how
Am 08.01.2020 um 14:47 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
> Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> > mailto:christian.bei...@gmail.com>
>
On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov
wrote:
> Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> > mailto:christian.bei...@gmail.com>> wrote:
> >
> > If a user enters a HQL literal, that user wants the literal to be
> >
Am 08.01.2020 um 13:50 schrieb Steve Ebersole:
> On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
> mailto:christian.bei...@gmail.com>> wrote:
>
> If a user enters a HQL literal, that user wants the literal to be
> rendered like that if possible(which should always be possible).
>
>
> Like
On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov
wrote:
> If a user enters a HQL literal, that user wants the literal to be
> rendered like that if possible(which should always be possible).
>
Like I said earlier, we actually try to render literals (of any type) as
parameters whenever we can
Actually Java and JDBC say that all of these Java 8 temporal types are
valid to pass via JDBC. It's done "implicitly" via the various
`#setObject` methods (as opposed to `#setTimestamp` e.g.).
Part of the problem here (6 and before) at the moment is that our
LocalDateTimeType, ZonedDateTimeType,
On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere wrote:
> > This does nothing with Type. The way the grammar is defined it
> literally understands each piece of the temporal. So given, e.g.,
> {2020-01-01}, we know that 2020 is the year, etc. This is the benefit of
> defining it syntactically.
>
If a user enters a HQL literal, that user wants the literal to be
rendered like that if possible(which should always be possible).
The only thing we have to define is whether the literal is by default in
the JVM TZ, JDBC TZ or UTC. We could offer syntax variants that default
to UTC etc.
Not
> Can't we just render a literal in the DBMS proprietary way as literal
again
> but with respective TZ information to avoid TZ issues in the JDBC driver?
This may be an option. We would need to take into account the default JVM
timezone, or the "jdbc_timezone" setting, to set the correct offset.
Can't we just render a literal in the DBMS proprietary way as literal again
but with respective TZ information to avoid TZ issues in the JDBC driver?
If we use an instant literal we use the UTC TZ in a SQL literal or function
to render that.
Yoann Rodiere schrieb am Mi., 8. Jän. 2020, 11:22:
>
> This does nothing with Type. The way the grammar is defined it literally
understands each piece of the temporal. So given, e.g., {2020-01-01}, we
know that 2020 is the year, etc. This is the benefit of defining it
syntactically.
I trust you can build a temporal correctly from a string. I'm
>
> As far as I know, even Java does not support that. A true zone-id would
> be something like (for me) "America/Chicago". If I ask Java to parse
> "2020-01-01 10:10:10 America/Chicago +02:00" it just says no. For me, CST
> (standard) and CDT (daylight savings) are really synonyms for offset -
On Tue, Jan 7, 2020 at 10:05 AM Yoann Rodiere wrote:
> On Tue, 7 Jan 2020 at 14:45, Steve Ebersole wrote:
>
>> Sorry, I should have been more clear. The literals are not "passed
>> through"; it's just a mechanism to be able to recognize the literal
>> syntactically while parsing. All of those
On Tue, 7 Jan 2020 at 14:45, Steve Ebersole wrote:
> Sorry, I should have been more clear. The literals are not "passed
> through"; it's just a mechanism to be able to recognize the literal
> syntactically while parsing. All of those forms I showed actually are
> handled in the code and
Thanks for the feedback.
I added some comments in-line.
On Tue, Jan 7, 2020 at 1:59 AM Yoann Rodiere wrote:
> Hi,
>
> The syntax looks nice.
> I suppose it's future-proof enough, though I can imagine us getting in
> trouble if JDBC starts allowing parameterized or custom formats, which may
>
Hi,
The syntax looks nice.
I suppose it's future-proof enough, though I can imagine us getting in
trouble if JDBC starts allowing parameterized or custom formats, which may
start with a digit or even (in edge cases) look like a date. That seems
unlikely, so I think it's an acceptable risk.
I'm
Initially when I started working on 6.0 I added support for defining
temporal literals using JDBC's "escape syntax". JDBC already defines a
syntax for declaring temporal literals using this syntax -
- {d '2020-01-01'} for a Date
- {t '10:10:10'} for a Time
- {ts '2020-01-01 10:10:10'}
27 matches
Mail list logo
