Thomas Munro <thomas.mu...@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
