65.years.ago on Windows XP

rubyonrails-talk
1

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

2

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

3

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

4

Try this:

65.years.ago.to_date

5

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