Rails - Sep 2005 - Date Validation: The February 31st Problem

Hi Railers,

I''m wondering if anyone has found a nice solution to the problem of
validating
dates to prevent things like 29th February 2005, or 31st September and so on?

I see it was discussed before...

http://wrath.rubyonrails.org/pipermail/rails/2005-March/003804.html

...but with no particularly ideal solution...

http://wrath.rubyonrails.org/pipermail/rails/2005-March/003815.html

I think it should give an standard ActiveRecord validation error back to the 
user saying "fieldname must be a valid date" - surely by now, someone
must
have cracked this problem?

I hope so!  If not, does anyone else who also needs a way of doing this ASAP 
fancy collaborating to find a good fix for it?  It just seems like a very 
obvious thing to include in the Rails core - that date processing should 
automatically make sure entered dates are properly valid dates.  Or is it not 
as simple as that?  (I guess not, otherwise it would have been done by now.)

Cheers,

~Dave

-- 

Dave Silvester
Rent-A-Monkey Website Development
Web: http://www.rentamonkey.com/

You may find this helpful.  I am in the middle of writing a Calendar
generating component. Here is a snippet that I use to determine the days_in a
year and month passed in.  Basically, you just need to hardcode the standard
cases, and then check for the leap year exception:

  @@days_in_month
{1=>31,2=>28,3=>31,4=>30,5=>31,6=>30,7=>31,8=>31,9=>30,10=>31,11=>30,12=>31}

  def days_in(year, month)
    return @@days_in_month[month] unless (month == 2 &&
Date.new(year,month,1).leap?)
    return 29 # leap year
  end

Tom

On 9/21/05, Dave Silvester <dave-AJqNGCqIqVQ7cdpDWioORw@public.gmane.org>
wrote:
> Hi Railers,
>
> I''m wondering if anyone has found a nice solution to the problem
of validating
> dates to prevent things like 29th February 2005, or 31st September and so
on?
>
> I see it was discussed before...
>
> http://wrath.rubyonrails.org/pipermail/rails/2005-March/003804.html
>
> ...but with no particularly ideal solution...
>
> http://wrath.rubyonrails.org/pipermail/rails/2005-March/003815.html
>
> I think it should give an standard ActiveRecord validation error back to
the
> user saying "fieldname must be a valid date" - surely by now,
someone must
> have cracked this problem?
>
> I hope so!  If not, does anyone else who also needs a way of doing this
ASAP
> fancy collaborating to find a good fix for it?  It just seems like a very
> obvious thing to include in the Rails core - that date processing should
> automatically make sure entered dates are properly valid dates.  Or is it
not
> as simple as that?  (I guess not, otherwise it would have been done by
now.)
>
> Cheers,
>
> ~Dave
>
> --
>
> Dave Silvester
> Rent-A-Monkey Website Development
> Web: http://www.rentamonkey.com/
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Dave Silvester wrote:
>Hi Railers,
>
>I''m wondering if anyone has found a nice solution to the problem of
validating
>dates to prevent things like 29th February 2005, or 31st September and so
on?
>  
>
You mean like Excel prevents the 29th February 1900 problem? :)

For those who don''t know, one of the first major spreadsheets, Lotus 
1-2-3, and maybe earlier ones, represented dates internally as "days 
since December 31, 1899", assuming that nobody would want to do anything 
with earlier values. Unfortunately, they also thought 1900 was a leap 
year, which it wasn''t. A number of succeeding spreadsheets decided they
needed to be upward compatible, so they used the same numeric code for 
dates. Try it some time; put the numbers from 1 to 100 into a column and 
format them as dates. :)

On the other hand, R, being built by an international team of 
statisticians, provides for leap *seconds*.

-- 
M. Edward (Ed) Borasky

http://www.borasky-research.net/
http://borasky-research.blogspot.com/

http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com