pgpdump states a key expiration time subpacket as an absolute time in
seconds since the epoch, but
https://tools.ietf.org/html/rfc4880#section-5.2.3.6 indicates that it
should be read as "seconds after key creation" instead.  compare with
gpg --list-packets:

0 dkg@alice:/tmp/cdtemp.Tvk0D4$ pgpdump < 000015-002.sig
Old: Signature Packet(tag 2)(549 bytes)
	Ver 4 - new
	Sig type - Subkey Binding Signature(0x18).
	Pub alg - RSA Encrypt or Sign(pub 1)
	Hash alg - SHA512(hash 10)
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used for authentication
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Wed Jan 21 15:54:17 EST 2015
	Hashed Sub: key expiration time(sub 9)(4 bytes)
		Time - Thu Aug  4 01:50:07 EDT 1977
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0xCCD2ED94D21739E9
	Hash left 2 bytes - 98 20
	RSA m^d mod n(4094 bits) - ...
		-> PKCS-1
0 dkg@alice:/tmp/cdtemp.Tvk0D4$ gpg2 --list-packets < 000015-002.sig
# off=0 ctb=89 tag=2 hlen=3 plen=549
:signature packet: algo 1, keyid CCD2ED94D21739E9
	version 4, created 1421873657, md5len 0, sigclass 0x18
	digest algo 10, begin of digest 98 20
	hashed subpkt 27 len 1 (key flags: 20)
	hashed subpkt 2 len 4 (sig created 2015-01-21)
	hashed subpkt 9 len 4 (key expires after 7y217d5h50m)
	subpkt 16 len 8 (issuer key ID CCD2ED94D21739E9)
	data: [4094 bits]
0 dkg@alice:/tmp/cdtemp.Tvk0D4$


in particular, the claim about 1977 in pgpdump is bogus :)

the example packet used in the test above is attached here.