diff options
| author | Ingo Klöcker <[email protected]> | 2026-02-05 14:44:34 +0100 |
|---|---|---|
| committer | Ingo Klöcker <[email protected]> | 2026-02-05 15:16:59 +0100 |
| commit | 021927f2f7be962d2549c978c262edd3f5c2da58 (patch) | |
| tree | a522f7276b816d2794f98155c47d59e9aa2adcd1 | |
| parent | Fix build with libassuan 2. (diff) | |
| download | gpgme-021927f2f7be962d2549c978c262edd3f5c2da58.tar.gz gpgme-021927f2f7be962d2549c978c262edd3f5c2da58.zip | |
Don't cap ISO dates beyond year 2037 on Windows
* src/conversion.c (_gpgme_parse_timestamp): On Windows, disable hack
for 32-bit time_t.
--
On Windows, SystemTimeToFileTime is used for converting the timestamp
to seconds since epoch and this API doesn't have a year 2038 problem.
GnuPG-bug-id: 8088
| -rw-r--r-- | src/conversion.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/conversion.c b/src/conversion.c index d299114b..d15d7cc9 100644 --- a/src/conversion.c +++ b/src/conversion.c @@ -585,10 +585,12 @@ _gpgme_parse_timestamp (const char *timestamp, char **endp) if (endp) *endp = (char*)(timestamp + 15); +#ifndef HAVE_W32_SYSTEM /* Fixme: We would better use a configure test to see whether mktime can handle dates beyond 2038. */ if (sizeof (time_t) <= 4 && year >= 2038) return (time_t)2145914603; /* 2037-12-31 23:23:23 */ +#endif memset (&buf, 0, sizeof buf); buf.tm_year = year - 1900; |
