Fix year 2039 bug for localtime with 64-bit time_t (bug 22639).

Fix year 2039 bug for localtime with 64-bit time_t (bug 22639).

Bug 22639 reports localtime failing to handle time offset transitions
correctly in 2039 and later on platforms with 64-bit time_t.

The problem is the use of SECSPERDAY (constant 86400) in calculations
such as

    t = ((year - 1970) * 365
	 + /* Compute the number of leapdays between 1970 and YEAR
	      (exclusive).  There is a leapday every 4th year ...  */
	 + ((year - 1) / 4 - 1970 / 4)
	 /* ... except every 100th year ... */
	 - ((year - 1) / 100 - 1970 / 100)
	 /* ... but still every 400th year.  */
	 + ((year - 1) / 400 - 1970 / 400)) * SECSPERDAY;

where t is of type time_t and year is of type int.  Before my commit
92bd70fb85bce57ac47ba5d8af008736832c955a (an update from tzcode,
included in 2.26 and later releases), SECSPERDAY was obtained from a
file imported from tzcode, where the value included a cast to
int_fast32_t.  On 64-bit platforms, glibc defines int_fast32_t to be
long int, so 64-bit, but my patch resulted in it changing to int.
(The bug would probably have existed even before my patch for x32,
which has 64-bit time_t but 32-bit int_fast32_t, but I haven't
verified that.)

This patch fixes the problem by including a cast to time_t in the
definition of SECSPERDAY.  (64-bit time support for 32-bit systems
should move such code that isn't a public interface to using the
internal 64-bit version of time_t throughout.)

Tested for x86_64 and x86.

	[BZ #22639]
	* time/tzset.c (SECSPERDAY): Cast to time_t.
	* time/tst-y2039.c: New file.
	* time/Makefile (tests): Add tst-y2039.