Bug #4291

rb_time_new with negative values (pre-epoch dates) on Windows

Added by banker (Kyle Banker) over 9 years ago. Updated over 9 years ago.

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


rb_time_new does not handle negative values (and thus pre-epoch dates) on windows. It seems like it should given that 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
=> 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.


Updated by naruse (Yui NARUSE) over 9 years ago

  • Status changed from Open to Rejected

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


Updated by zimbatm (zimba tm) over 9 years ago

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



Updated by naruse (Yui NARUSE) over 9 years ago

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

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.

Also available in: Atom PDF