bug#19302: 24.4.51; `date-to-time' fails after 2038

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> Date: Tue, 09 Dec 2014 06:01:26 -0500  From: Richard Stallman

 >>> If I remember correctly, there are OS-es out there that have a
 >>> 32-bit time_t?

 >> Apparently so -- that is why I suggest making Emacs use 64 bits even
 >> if the operating system uses 32 bits.

 > What do you do with time_t fields of 'struct stat', 'struct timeval',
 > and other structures used by library functions?  They will still wrap
 > around.

        How would that affect a function whose purpose is not to pass
        such a time value to some library call?

        And when a value /is/ passed to the underlying platform, it can
        be checked if it fits the target type, and the error signalled
        if it doesn’t.

        In the case of date-to-time, the likely culprit is encode-time,
        which is (more or less) a wrapper around mktime ().  Granted,
        Emacs may use Gnulib’s mktime.c, but it doesn’t seem to provide
        a 64-bit variant of mktime () suitable for systems with 32-bit
        time_t, either.

        Thus, the real question is: do we want some kind of time64_t
        support in Gnulib, and if so, who’d volunteer to implement it?

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A