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.
Given that ruby can't support that value, coercing to nil seems at
least reasonable.
Hmm. That doesn't negate the ability to at least conduct searches based
on what the db can contain, but it's a valid point in that it makes
implementing full support for it difficult. OK, well, that settles that.
I'll drop it.
From an app code perspective, one way around this inability is to use
varchar for dates (in the ISO format). I've done that before too in a
few cases where a variety pf reasons made using varchars for dates
easier to work with (casting on demand when needed for calculations).
It's nice to not have to do that, but it works.
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...)