test implementation handling of timestamps with high bit set

timestamps in OpenPGP are 32-bit unsigned integers that count seconds since the unix epoch. (expiration times are measured as offsets from creation time, so looking at expiration times they could be as large as 2^33 seconds after the unix epoch.

Some platforms have internal time_t values that are 32-bit signed integers that count seconds since the unix epoch.

these 32-bit time_ts will overflow in 2038, while OpenPGP timestamps will overflow in 2106 (and expiration dates will overflow in 2242)

It would be good to have some tests that exercise timestamps in the regions between 2038 and 2106 to ensure that implementations don't choke on them. It might also be good to exercise some expiration timestamps between 2106 and 2242.

Given that (signature or key) creation timestamps in the suggested range are effectively in the future, some reasonable implementations might legitimately refuse to process them anyway. i'm not sure how to best test this without using faketime or datefudge to convince the tooling that "now" is in that range as well, but i'm open to suggestions.