Bug #4291
closedrb_time_new with negative values (pre-epoch dates) on Windows
Description
=begin
rb_time_new does not handle negative values (and thus pre-epoch dates) on windows. It seems like it should given that Time.at does.
ruby 1.9.2p136 (2010-12-25) [i386-mingw32]
Pure ruby does work:
irb(main):005:0> sec = Time.utc(1600).to_f
=> -11676096000.0
irb(main):012:0> Time.at(sec).utc
=> 1600-01-01 00:00:00 UTC
But in a C extension, it does not work:
value = rb_time_new(-11676096000, 0);
value = rb_funcall(value, utc_method, 0);
This results in a Time object with this value:
2008-04-21 19:24:48 UTC (12884901888.0)
Where we wanted 1600-01-01
Note that the problem in on Windows only. Other platforms work fine.
=end
Updated by naruse (Yui NARUSE) almost 14 years ago
- Status changed from Open to Rejected
=begin
-11676096000 exceeds 32bit long.
On i386-mingw32, long is 32bit (on mswin32 long is of course 32bit, and mswin64 is also 32bit because mswin64 is LLP64)
"Other platforms"'s long seem 64bit.
=end
Updated by zimbatm (zimba tm) almost 14 years ago
=begin
Shouldn't we use 64bit on all platforms instead ?
=end
Updated by naruse (Yui NARUSE) almost 14 years ago
=begin
My previous comment is not accurate and enough helpful.
rb_time_new's prototype is VALUE rb_time_new(time_t sec, long usec).
so this is depends on sizeof(time_t).
mingw32's time_t seems 32bit.
This means the year 2038 problems, and you hit the negative version of Y2038.
See also http://lists-archives.org/mingw-users/16064-year-2038-problems-32bit-time_t.html
And before 1.9.2 Time object's internal representation is time_t.
So with first one, you can't avoid this.
On 1.9.2 you can use rb_time_num_new().
Its argument is VALUE, so you can use Bignum.
=end