In article <7CE19CBC-71C5-48FE-A2E7-4FCE489A7090 / gmail.com>,
  Dirkjan Bussink <d.bussink / gmail.com> writes:

> The tm_year member must be for year 1901 or later. Calendar times  
> before 20:45:52 UTC,  December 13, 1901 or after 03:14:07 UTC, January  
> 19, 2038 cannot be represented. Port-      able applications should  
> not try to create dates before 00:00:00 UTC, January 1, 1970 or after  
> 00:00:00 UTC, January 1, 2038.

It is a bug of mktime.

POSIX describes that mktime shall return (time_t)-1 for such condition.

| RETURN VALUE
| 
|     The mktime() function shall return the specified time since the Epoch
|     encoded as a value of type time_t. If the time since the Epoch cannot be
|     represented, the function shall return the value (time_t)-1.

So POSIX application can rely on this behavior.

However glibc has a bug.

I reported it to Debian GNU/Linux (etch).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444597

Newer glibc fixed the bug.
(So matz doesn't see the bug.  He use the newer glibc.)

> The easiest solution is to simply remove the mktime() call and always  
> use localtime() which exhibits the correct behavior. I've tested this,  
> and this results in the correct behavior.

mktime and timegm is required for the edge of possible range
on 64 bit time_t environment.

It is the year -(1<<32)+1900 and (1<<32)-1+1900 but exact
limit depends on the timezone.

However it may be good to verify mktime/timegm result using
localtime/gmtime.
-- 
Tanaka Akira