Re: postgresql 7.3.2 bug on date '1901-12-13' and '1901-12

"ir. F.T.M. van Vugt bc." <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> free4testing=# select timestamptz '1901/12/13 23:59:59.999999999';
> timestamptz
> ---------------------------
> 1901-12-14 00:19:00+00:19
> (1 row)

> Yes, that's a new timezone on the second case, indeed, probably a kind of
> 'floating' one ;-)

This is apparently because the Europe/Amsterdam time zone file actually
tries to reflect the wacky local time used back then:

#
# Amsterdam Mean Time was +00:19:32.13 exactly, but the .13 is omitted
# below because the current format requires GMTOFF to be an integer.
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Europe/Amsterdam 0:19:32 - LMT 1835
0:19:32 Neth %s 1937 Jul 1
0:20 Neth NE%sT 1940 May 16 0:00 # Dutch Time
1:00 C-Eur CE%sT 1945 Apr 2 2:00
1:00 Neth CE%sT 1977
1:00 EU CE%sT

The display *ought* to be 00:19:32+00:19, but Postgres drops the seconds
part because it is not expecting the timezone offset to have a seconds
component --- which it is doing to work around a bug that may or may not
still exist in the wild:

tm->tm_hour = tx->tm_hour;
tm->tm_min = tx->tm_min;
#if NOT_USED
/* XXX HACK
* Argh! My Linux box puts in a 1 second offset for dates less than 1970
* but only if the seconds field was non-zero. So, don't copy the seconds
* field and instead carry forward from the original - thomas 97/06/18
* Note that GNU/Linux uses the standard freeware zic package as do
* many other platforms so this may not be GNU/Linux/ix86-specific.
* Still shows a problem on my up to date Linux box - thomas 2001-01-17
*/
tm->tm_sec = tx->tm_sec;
#endif

I can't reproduce the bug Thomas mentions on an RH 8.0 system, but I'm
afraid to remove the workaround, as it could affect a lot of people in
order to fix a case that's not of much practical interest anymore...

regards, tom lane