On Jul 30, 2024, at 07:59, Andrew Dunstan wrote:
> I have pushed this.
Thank you, Andrew!
D
On 2024-07-22 Mo 3:12 AM, Jeevan Chalke wrote:
On Fri, Jul 19, 2024 at 7:35 PM David E. Wheeler
wrote:
On Jul 10, 2024, at 11:19, David E. Wheeler
wrote:
> Oh, and the time and date were wrong, too, because I blindly
used the same conversion for dates as for timestamps. F
On Jul 22, 2024, at 03:12, Jeevan Chalke wrote:
> I agree with David that we need to set the tz explicitly as the JsonbValue
> struct maintains that separately.
>
> However, in the attached version, I have added some comments and also, fixed
> some indentation.
Thank you for the review. I cha
On Fri, Jul 19, 2024 at 7:35 PM David E. Wheeler
wrote:
> On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
>
> > Oh, and the time and date were wrong, too, because I blindly used the
> same conversion for dates as for timestamps. Fixed in v2.
> >
> > PR: https://github.com/theory/postgres/pull
On Jul 10, 2024, at 11:19, David E. Wheeler wrote:
> Oh, and the time and date were wrong, too, because I blindly used the same
> conversion for dates as for timestamps. Fixed in v2.
>
> PR: https://github.com/theory/postgres/pull/7
> CF: https://commitfest.postgresql.org/49/5119/
Rebase on 57
On Jul 10, 2024, at 10:54, David E. Wheeler wrote:
> So it should be -7, not -8. Not sure where to tell it to pay proper attention
> to daylight savings time.
Oh, and the time and date were wrong, too, because I blindly used the same
conversion for dates as for timestamps. Fixed in v2.
PR: ht
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
Actually I think there’s a subtlety still missing here:
@@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
select jsonb_path
On Jul 10, 2024, at 10:33, David E. Wheeler wrote:
> Yeah I don’t know either, but now at least it’s consistent. I’ve attached a
> patch to fix it.
>
> Ideally, I think, we wouldn’t convert the value and determine the offset
> twice, but teach date_timestamptz and timestamp_timestamptz (or
>
On Jul 10, 2024, at 01:48, Junwang Zhao wrote:
> I apply your patch with some minor change(to make the server not crash):
Oh, thank you! Kicking myself for not catching the obvious.
> It now gives the local tz:
>
> [local] postgres@postgres:5432-54960=# set time zone 'America/New_York';
> SET
On Tue, Jul 9, 2024 at 11:38 PM David E. Wheeler wrote:
>
> On Jul 9, 2024, at 11:08, Junwang Zhao wrote:
>
> > In JsonbValue.val.datatime, there is a tz field, I think that's where
> > the offset stored, it is 18000 in the first example
> >
> > struct
> > {
> > Datum value;
> > Oid typid;
> > in
On Jul 9, 2024, at 11:08, Junwang Zhao wrote:
> In JsonbValue.val.datatime, there is a tz field, I think that's where
> the offset stored, it is 18000 in the first example
>
> struct
> {
> Datum value;
> Oid typid;
> int32 typmod;
> int tz; /* Numeric time zone, in seconds, for
> * Time
On Tue, Jul 9, 2024 at 10:22 PM David E. Wheeler wrote:
>
> On Jul 9, 2024, at 10:07, David E. Wheeler wrote:
>
> > So perhaps I had things reversed before. Maybe it’s actually doing the
> > right then when it converts a timestamp to a timestamptz, but not when it
> > the input contains an offs
On Jul 9, 2024, at 10:07, David E. Wheeler wrote:
> So perhaps I had things reversed before. Maybe it’s actually doing the right
> then when it converts a timestamp to a timestamptz, but not when it the input
> contains an offset, as in your example.
To clarify, there’s an inconsistency in the
> On Jul 8, 2024, at 21:44, Junwang Zhao wrote:
>
> # select jsonb_path_query_tz('"2024-08-15 12:34:56-05"', '$.timestamp_tz()');
>
> Do you also expect this to show the time in America/New_York?
>
> This is what I get:
>
> [local] postgres@postgres:5432-28176=# select
> jsonb_path_query_tz
On Mon, Jul 1, 2024 at 11:02 PM David E. Wheeler wrote:
>
> Hackers,
>
> There’s an odd difference in the behavior of timestamp_tz() outputs. Running
> with America/New_York as my TZ, it looks fine for a full timestamptz,
> identical to how casting the types directly works:
>
> david=# set time
On Jul 2, 2024, at 10:53, David E. Wheeler wrote:
> ``` patch
> --- a/src/test/regress/expected/jsonb_jsonpath.out
> +++ b/src/test/regress/expected/jsonb_jsonpath.out
> @@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support.
> select jsonb_path_query_tz('"2023-08-15"', '$.timesta
On Jul 1, 2024, at 11:02, David E. Wheeler wrote:
> Anyway, should the output of timestamptz JSONB values be made more
> consistent? I’m happy to make a patch to do so, but could use a hand figuring
> out where the behavior varies.
I think if the formatting was more consistent, the test output
Hackers,
There’s an odd difference in the behavior of timestamp_tz() outputs. Running
with America/New_York as my TZ, it looks fine for a full timestamptz, identical
to how casting the types directly works:
david=# set time zone 'America/New_York';
SET
david=# select '2024-08-15 12:34:56-04'::
18 matches
Mail list logo
