Bug #4291: rb_time_new with negative values (pre-epoch dates) on Windows

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 1.9.2p136 (2010-12-25) [i386-mingw32]

[banker (Kyle Banker)]

=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

[naruse (Yui NARUSE)]

• 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

[zimbatm (zimba tm)]

=begin
Shouldn't we use 64bit on all platforms instead ?

=end

[naruse (Yui NARUSE)]

=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