From: Dirkjan Bussink Date: 2007-12-28T07:37:46+09:00 Subject: Invalid use of mktime() in Ruby 1.8/1.9 results in incorrect Time objects Hello, I've found a bug in both Ruby 1.8 and 1.9, which occurs on systems that have Ruby compiled with HAVE_MKTIME. According to the man page: 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. The warning issued here is exactly what happens in both 1.8 and 1.9. If Ruby is compiled with HAVE_MKTIME, the code eventually falls through to the following line in time.c (1.9 trunk): 846 #if defined(HAVE_MKTIME) 847 if ((t = mktime(&buf)) != -1) 848 return t; 849 #ifdef NEGATIVE_TIME_T 850 if ((tmp = localtime(&t If the Ruby call is for example Time.local(1900), the behavior of mktime apparently is to create a time object for 20:45:52 UTC, December 13, 1901 instead of returning -1. Whether or not this is correct behavior is not really an issue, because this behavior is not defined in the mktime() specification. The expected behavior from Ruby's point of view is that is should raise an ArgumentError: time out of range. 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. All this has been tested on a clean Debian Etch install with the latest Ruby compiled from trunk. -- Regards, Dirkjan Bussink