the C specification only requires that long be at least 32 bits wide.
On a platform where unsigned long is a 32-bit integer, this cannot represent values larger than 2106-02-07 06:28:16 UTC. This means that (for example) a signature due to expire 87 years from today will be unrepresentable on such a platform (or, perhaps more troublingly, will appear to have an expiration date in the past).
I have no examples of such a signature to point to today, but 32 bit platforms have proved remarkably persistent, and some might still be relevant at a time when they could plausibly encounter a 2106 expiration date.
I'm not sure of the right way to fix this, since fixing it properly will likely be both an API and an ABI change in GPGME.
For the OpenPGP engine for GPGME, this is irrelevant for creation times, because they are bound to 4 byte unsigned integers in the first place. But it is still relevant for expiration time markers: both Key Expiration Time and Signature Expiration Time subpackets are *offsets* from their corresponding creation time subpackets. So the computed expiration value can surpass 2^32 seconds since the epoch.
For the CMS engine for GPGME, this is relevant because CMS "validAfter" and "validBefore" times are typically represented as a GeneralizedTime object, which can represent up to the year 9999.
I can create objects that have values in the relevant time regions if having a test case would help to resolve the matter.