65.years.ago on Windows XP

Hello,

I've some trouble with years.ago I want so use in calendar_date_select as
described here:
http://code.google.com/p/calendardateselect/wiki/CalendarDateSelectParameters
I wrote:
       <%= contact.calendar_date_select :birth_date, {:size => 10, :label
=> 'Birthday',:year_range => [65.years.ago, 0.years.from_now]} %></td>

But years.ago seems to be bound to the OS'es time-routines, that is quite
annoying:

eg.
Linux:
ruby script/console
Loading development environment.

65.years.ago

=> Mon Jan 11 06:21:12 +0100 1943

Windows XP 32-Bit
ruby script/console
Loading development environment.

65.years.ago

ArgumentError: time must be positive
        from
W:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/numeric/time.rb:56:in
`-'
        from
W:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/core_ext/numeric/time.rb:56:in
`ago'
        from (irb):1

Is there a way to work around this issue - MySQL has no trouble saving dates
down to 1000 anno domini....

Thanks,
Keep smiling
yanosz

In windows XP, ruby 1.8.6, recently updated win32 gems, Rails 2.0.2
Rails console:

1.years.ago

=> Thu Jan 11 13:52:19 +0200 2007

65.years.ago

=> Mon, 11 Jan 1943 13:52:27 +0200

Time.now

=> Fri Jan 11 13:52:57 +0200 2008

It works for me. The musta fixed it.
Try also
> gem outdated
to get a list of gems that aren't the most recent. Could be rails,
could be the win32 gems, I guess.

F

65.years.ago brings you well before the generally accepted Epoch of January 1, 1970. Thus the unix timestamp turns negative, and the reason for the error. Not that it’s right to fail that way, however.

Also MySQL has its own way of storing dates that doesn’t use the timestamp, at least not obviously, so it doesn’t make sense to compare the two.

Jason

Try this:

65.years.ago.to_date

<%= contact.calendar_date_select :birth_date, {:size => 10,
:label => 'Birthday',:year_range => Time.now.year-65..Time.now.year} %>