tweaked readme

changed mixed validation spec to datetime value out of Time range

README

@@ -84,9 +84,9 @@ The temporal options can take 4 different value types:
   * Proc or lambda object
   * A symbol matching the method name in the model  
 
-When values are compared for temporal options, they are compared as the same type
+When an attribute value is compared to temporal options, they are compared as 
-as the validation method type. So validates_date means all values are compared 
+the same type as the validation method type. So validates_date means all values
-as dates.
+are compared as dates.
 
 == EXAMPLES:
 
@@ -112,19 +112,20 @@ be happy to know that is exactly the format you can use to define your own if
 you want. No regular expressions or duck punching (monkey patching) the plugin.
 
   Time formats:  
-    hh:nn:ss  => 01:23:59
+    hh:nn:ss
-    hh-nn-ss  => 01:23:59
+    hh-nn-ss
-    h:nn      => 1:23 or 01:23
+    h:nn
-    h.nn      => 1.23 or 01.23
+    h.nn
-    h nn      => 1 23 or 01 23
+    h nn
-    h-nn      => 1-23 or 01-23
+    h-nn
-    h:nn_ampm => 1:23am or 1:23 am or 01:23am
+    h:nn_ampm
     h.nn_ampm 
     h nn_ampm
     h-nn_ampm
     h_ampm
   
-  NOTE: Any time format without a ampm token or meridian is considered in 24 hour time.
+  NOTE: Any time format without a meridian value or ampm token is considered 
+        in 24 hour time.
   
   Date formats:  
     yyyy/mm/dd
@@ -136,7 +137,7 @@ you want. No regular expressions or duck punching (monkey patching) the plugin.
     d.m.yy
     d mmm yy
   
-  NOTE: to switch to using non-US date formats see US/EURO FORMATS section
+  NOTE: To use non-US date formats see US/EURO FORMATS section
   
   Datetime formats:  
     m/d/yy h:nn:ss   OR  d/m/yy hh:nn:ss
@@ -147,7 +148,7 @@ you want. No regular expressions or duck punching (monkey patching) the plugin.
     ddd mmm d hh:nn:ss zo yyyy # Ruby time string
     yyyy-mm-ddThh:nn:ss(?:Z|zo) # ISO 8601
 
-  NOTE: to switch to using non-US date formats see US/EURO FORMATS section
+  NOTE: To use non-US date formats see US/EURO FORMATS section
 
 Here is what each format token means:
 
@@ -164,13 +165,6 @@ Here is what each format token means:
       tz = Timezone abbreviation (e.g. UTC, GMT, PST, EST)
       zo = Timezone offset (e.g. +10:00, -08:00, +1000)
 
-All other characters are considered literal. You can embed regular expressions
-in the format but no gurantees that it will remain intact. If you avoid the use
-of any token characters and regexp dots or backslashes as special characters 
-in the regexp, it may well work as expected. For special characters use 
-POSIX character clsses for safety. See the ISO 8601 datetime for en example of 
-of an embedded regular expression.
-
   Repeating tokens:        
        x = 1 or 2 digits for unit (e.g. 'h' means an hour can be '9' or '09')
       xx = 2 digits exactly for unit (e.g. 'hh' means an hour can only be '09')
@@ -182,7 +176,8 @@ of an embedded regular expression.
      ddd = Day name of 3 to 9 letters (e.g. Wed or Wednesday)
        u = microseconds matches 1 to 3 digits
 
-For the technically minded (well you are developers), these formats are compiled
+All other characters are considered literal. For the technically minded 
+(well you are developers), these formats are compiled
 into regular expressions at runtime so don't add any extra overhead than using
 regular expressions directly. So, no, it won't make your app slow!
 
@@ -212,12 +207,18 @@ remove a format stick this in an initializer file or environment.rb
 
 Done! That format is no longer considered valid. Easy!
 
+You can embed regular expressions in the format but no gurantees that it will 
+remain intact. If you avoid the use of any token characters and regexp dots or 
+backslashes as special characters in the regexp, it may well work as expected. 
+For special characters use POSIX character clsses for safety. See the ISO 8601 
+datetime for en example of of an embedded regular expression.
+
 Ok, now I hear you say "Well I have format that I want to use but you don't have it".
 Ahh, then add it yourself. Again stick this in an initializer file or environment.rb.
 
     ValidatesTimeliness::Formats.add_formats(:time, "d o'clock")
 
-Now '10 o'clock' will be a valid value. So easy, no more whingeing!
+Now "10 o'clock" will be a valid value. So easy, no more whingeing!
 
 Because formats are evaluated in order, adding a format which may be ambiguous 
 with an existing format, will mean your format is ignored. If you need to make

lib/validates_timeliness/validations.rb

@@ -24,9 +24,6 @@ module ValidatesTimeliness
       # Chronic. Just return nil for an invalid value and a Time object for a 
       # valid parsed value. 
       # 
-      # Remember to attempt fallback to back to a DateTime if the Time object is
-      # out of range. Range for Ruby Time class on 32-bit *nix is down to about
-      # 1902-01-01 and 1970-01-01 for Windows.
       def timeliness_date_time_parse(raw_value, type, strict=true)
         return raw_value.to_time if raw_value.acts_like?(:time) || raw_value.is_a?(Date)
         

spec/validations_spec.rb

@@ -336,8 +336,9 @@ describe ValidatesTimeliness::Validations do
       @person.errors.on(:birth_date_and_time).should match(/must be after/)
     end
 
-    it "should correctly validate date attribute with Time restriction" do
+    it "should correctly validate date attribute with DateTime restriction" do
       @person.birth_date = "2008-01-03"
+      @person.birth_date_and_time = "1890-01-01 00:00:00"
       @person.should_not be_valid
       @person.errors.on(:birth_date).should match(/must be on or before/)
     end