Re: Add support for AT LOCAL

Thomas Munro <thomas.munro@gmail.com> writes:
> One of the AIX animals gave a strange result here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2023-10-15%2011%3A40%3A01

> If you ignore the diffs due to change in column width, the interesting
> change seems to be:

> -  23:59:00-07    | 06:59:00+00    | 06:59:00+00    | 06:59:00+00
> -  23:59:59.99-07 | 06:59:59.99+00 | 06:59:59.99+00 | 06:59:59.99+00
> +  23:59:00-07    | 4294966103:4294967295:00+00 |
> 4294966103:4294967295:00+00 | 4294966103:4294967295:00+00
> +  23:59:59.99-07 | 4294966103:00:00.01+00      |
> 4294966103:00:00.01+00      | 4294966103:00:00.01+00

> But the other AIX animal 'sungazer' was OK with it.  They're both on
> the same AIX7.1 host IIRC, both 64 bit builds, but the former is using
> xlc and the latter gcc.  I don't immediately see what would cause that
> underflow on that old compiler but not elsewhere.  I have a shell
> there (cfarm111) if someone has an idea...

Hmm.  Seems like the error has to be creeping in during this part
of timetz_zone():

    result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
    while (result->time < INT64CONST(0))
        result->time += USECS_PER_DAY;
    while (result->time >= USECS_PER_DAY)
        result->time -= USECS_PER_DAY;

According to my machine, the initial computation of result->time
(for the '23:59:59.99-07' input) yields 111599990000, and then we
iterate the second loop once to get 25199990000, which is the right
answer.  If I force a second iteration to get -61200010000, I get

# select '23:59:59.99-07'::timetz at local;
        timezone
------------------------
 4294967279:00:00.01+00
(1 row)

which doesn't quite match hornet's result but it seems
suggestively close.

Another line of thought is that while the time fields are int64,
t->zone and tz are only int32.  Multiplying by the INT64CONST
USECS_PER_SEC ought to be enough to make the compiler widen
the subtraction result to int64, but maybe that's screwing up?
I'm tempted to wonder if this helps:

-    result->time = t->time + (t->zone - tz) * USECS_PER_SEC;
+    result->time = t->time + (int64) (t->zone - tz) * USECS_PER_SEC;

Forcing the wrong thing to happen there doesn't produce a match
to hornet's result either, so I don't have a lot of hope for that
theory, but it seems like the explanation has to be somewhere here.

            regards, tom lane