But we don't have any timezones on this planet that has an offset that needs second granularity, do we? I wonder what the use case for this is in PostgreSQL?

I had the same thought when it came up in testing, as it is not documented in the PostgreSQL docs. It seems to be some sort of fallback for ranges where PostgreSQL can't find the timezone data.

SELECT make_timestamptz(1895, 9, 15, 5, 30, 0.00, '-05:30:00');
=> "1895-09-15 06:00:00-05"

SELECT make_timestamptz(1894, 9, 15, 5, 30, 0.00, '-05:30:00');
=> "1894-09-15 05:42:28-05:17:32"

The problem arose because our testers entered '1111-11-11 11:11:11' as the date and time. PostgreSQL does this:

SELECT make_timestamptz(1111, 1, 11, 11, 11, 11.00, 'UTC');
=> "1111-11-11 05:53:39-05:17:32"

Tracing this further, it seems that PostgreSQL falls back to the system timezone if it can't make sense of the input. By default, the system timezone is 'localtime', which is equivalent to the entry in the zoneinfo database.

The zoneinfo database does express offsets with second precision:

Zone America/Toronto	-5:17:32 -	LMT	1895

PHP internally does support these second offset timezones. And Toronto is by no means the only locality with this "issue". For example:

<?php
date_default_timezone_set("Europe/Amsterdam");

$dt1 = new DateTimeImmutable("Wed Jun 30 23:59:59 1937");
echo $dt1->format(DateTime::ISO8601 . ' \i\n \s\e\c: Z'), "\n";

$dt2 = $dt1->modify("+1 second");
echo $dt2->format(DateTime::ISO8601 . ' \i\n \s\e\c: Z'), "\n";
?>

Produces:

1937-06-30T23:59:59+0119 in sec: 4772
1937-07-01T00:00:28+0120 in sec: 4800

However, the ISO 8601 standard that we use for parsing and formatting timezone offsets only allows "+hh:mm, +hhmm, or +hh" [1] and hence PHP doesn't understand parsing "2015-09-15 01:15-05:30:30". Unfortunately, the whole parser only caters for minute resolution here, and overhauling this is not going to be an easy feat.

[1] http://www.cl.cam.ac.uk/~mgk25/iso-time.html

We encountered this bug when we developed application for timezone Europe/Luxembourg and used historic dates (1900-01-01 00:00:00) and we have found that at that times they used timezone with +00:24:36. (There is also another such timezone Paris Mean Time, see https://www.timeanddate.com/time/time-zones-history.html).

Also as p@wspnr.com thinks this is clearly a problem of interoperability, especially with PostgreSQL.

As the Olson-DB also contains the second-offset (https://github.com/eggert/tz/blob/c040ac6cb98d8c564a67e37468512d3e0447080b/europe#L1282) we should perhaps rethink about that, even though ISO only talks about HH:MM-Offset. But they don't specifically disallow the usage of seconds for offset…