From: Yukihiro Matsumoto <matz@...>
Date: 2007-12-28T08:45:09+09:00
Subject: Re: Invalid use of mktime() in Ruby 1.8/1.9 results in incorrect Time objects

Hi,

In message "Re: Invalid use of mktime() in Ruby 1.8/1.9 results in incorrect Time objects"
    on Fri, 28 Dec 2007 07:37:46 +0900, Dirkjan Bussink <d.bussink@gmail.com> writes:

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

Yes, we know.

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

I don't think so.  Have you tried?

  % ruby -e 'Time.local(1900)'
  -e:1:in `local': time out of range (ArgumentError)
	from -e:1:in `<main>'
  % ruby -e 'Time.local(1901,12,13)'
  -e:1:in `local': time out of range (ArgumentError)
	from -e:1:in `<main>'
  % ruby -e 'Time.local(1901,12,14)'
  1901-12-14 00:00:00 +0000

(I ran it in UTC timezone.)

|The expected behavior from Ruby's point of view is that is should  
|raise an ArgumentError: time out of range.

I am not sure what you mean by "expected behavior" here.  It seems
Ruby (both 1.8 and 1.9) works you expected on _my box_, Debian sid.
Does yours work differently?

							matz.