[MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit (Richard Sepulveda)

[Vincent Isambart]

> My conclusions,
> - 0.7 and 0.9 fix return the correct time now, 0.9 fix can't do necessary time arithmetic
> - Ruby Time.to_f is broken in all 3 versions
> - Bignum.to_f is broken in all 3 versions
> - I believe the to_f method is behind all of these problems but i haven't had time to find the problem nor
> a solution.

Your problems with #to_f are due to the fact that 32-bit MacRuby stores floats in 30 bits (MRI stores them in objects in 64 bits,  64-bit MacRuby stores them in 62 bits). The reason is mainly speed related (and we also don't have to garbage-collect them). At some time I think we had 32-bit mode using objects for storing them like MRI, and 64-bit mode using 62 bits but we decided to handle them the same way in both modes to have less code to maintain.

Seeing that very few people using 32-bit (and we will probably stop "supporting" it after 0.9), you will never get the precision you want from them. What you can do with MacRuby's current state though:
- if you don't need sub-second precision, use #to_i and do computations in integers (you can us Time.at to bring them back in Time instances),
- if you really need sub-second prevision, you would have to use BigDecimal. To convert a Time into BigDecimal: BigDecimal.new("%d.%06d" % [time.tv_sec, time.tv_usec]). To convert a BigDecimal back to time: Time.at(bd.to_i, (bd * 1000000).to_i % 1000000)