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

[Ivan Shmakov <ivan@siamics.net>]

>>>>> 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