Jordi Bunster wrote: > On Nov 26, 2007, at 9:40 PM, Michael Koziarski wrote: > >>> I would argue this is not an issue of "most" or even "standard" -- >>> most >>> code on the planet is probably written with camelCase names -- which >>> doesn't seem to have much impact on Rails' opinion. >> >> The real problem is that you *can't* retrieve that data again. Rails >> needs to coerce those values into a Date or Time, neither of which >> accept 0000-00-00. So we can't support it when reading data, there's >> not much point letting you write it. After all, you can't construct >> the time object to save in the first place. > > What about 0? Then the OP could test with .zero?
What's "OP" ? I think Koz's point is that with Rails doing auto-type-casting upon reading the data, it's going to take anything that Ruby rejects and convert it to nil. We could push the issue further by asking the rejected value be cast into a string so at least we get the value actually in the database, but I see even stronger resistanec to that as it would then require the app code to check for three possible object classes (Date, String, Nil) instead of two (Date, Nil) -- since most of these guy apparently don't see value in 0000-00-00 to start with, I think that's a losing proposition. So, whether its 0 or 0000-00-00 doesn't really matter, it's an added condition born out of distrusting the data type (err, Class) of an object. Nobody's going to care for that much. I'd still be curious about where in Rails, one could tap in to override the default behavior (for some legacy needs), but I can see them not adding it to core because of the native behavior of Ruby. In my past work, the native language could tell the difference, so the whole 0000-00-00 could be supported across the board as a valid third representation for dates. If Ruby isn't going to offer that, then Rails has to do a lot of work to get around it (and it's obvious that there's not a lot of motivation for them to do that). If an app really has to have this, like some of my legacy stuff does, the easiest way to get there is to use varchars for dates, add the three-class testing in the app code, and handle the type casting in the app models. It's a bummer, but it can be done. (hmm, if I were a politician I'd be accused of flip-flopping right about now, but hey, when the writing is on the wall...) -- gw -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
