Re: Add support for AT LOCAL

Thomas Munro <thomas(dot)munro(at)gmail(dot)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