README.md in sinatra-param-1.2.1

- old
+ new

@@ -1,7 +1,7 @@
 # sinatra-param
-_Parameter Contracts for Sinatra_
+_Parameter Validation & Type Coercion for Sinatra_
 
 REST conventions take the guesswork out of designing and consuming web APIs. Simply `GET`, `POST`, `PATCH`, or `DELETE` resource endpoints, and you get what you'd expect.
 
 However, when it comes to figuring out what parameters are expected... well, all bets are off.
 
@@ -48,10 +48,11 @@
 - `Integer`
 - `Float`
 - `Boolean` _("1/0", "true/false", "t/f", "yes/no", "y/n")_
 - `Array` _("1,2,3,4,5")_
 - `Hash` _(key1:value1,key2:value2)_
+- `Date`, `Time`, & `DateTime`
 
 ### Validations
 
 Encapsulate business logic in a consistent way with validations. If a parameter does not satisfy a particular condition, a `400` error is returned with a message explaining the failure.
 
@@ -89,10 +90,10 @@
         "order": "Param must be within [\"ASC\", \"DESC\"]"
     }
 }
 ```
 
-To change this, you can set `:raise_sinatra_param_exceptions` to `true`, and intercept `Sinatra::Param::InvalidParameterError` with a Sinatra `error do...end` block. (To make this work in development, set `:show_exceptions` to `false`):
+To change this, you can set `:raise_sinatra_param_exceptions` to `true`, and intercept `Sinatra::Param::InvalidParameterError` with a Sinatra `error do...end` block. (To make this work in development, set `:show_exceptions` to `false` and `:raise_errors` to `true`):
 
 ```ruby
 set :raise_sinatra_param_exceptions, true
 
 error Sinatra::Param::InvalidParameterError do