[LRUG] How does Rails decide how to parse ambiguous dates?

[John Winters]

On 27/07/11 10:26, Murray Steele wrote:
[snip]
> The major problem is that rails apparently tries to hide a lot of this
> strings being coerced into objects stuff and somewhat inexplicably
> pushes most of it down to the db adapter.  So you may get different
> results depending on if you are using something like sqlite
> (everything's a string, yay!) vs. postgres (a real database).

That's an interesting point - all my tests so far have been done using 
Sqlite3.  <attribute_name>_before_type_cast always returns a string and 
for a date it's always of the form "2011-07-27".  Date#to_s isn't being 
invoked, but it's possible that String#to_s is.

I suppose for full understanding I should also test with MySql and 
PostgreSQL to see if the behaviour changes.  If 
<attribute_name>_before_type_cast then returns some sort of date then 
the format strings might have some effect.

For a practical solution, I've gone with the earlier suggestion which 
you mention also and used ":value => ...".  Someone else suggested using 
month names as well for maximum unambiguity, and I've ended up having my 
dates in the form:

Wed 27 Jul, 2011

which both Rails and JQuery-UI can handle.  Being a traditionalist, I'd 
prefer:

Wed 27th Jul, 2011

but whilst Rails can cope with that, JQuery-UI can't.

> I hope this helps, or at last, doesn't confuse you more.

It helps - things are slowly becoming clearer.

Cheers,
John