> What are people take on empty dates?
> This is a problem, because we need to be able to have empty dates. Also,
> enetering something magick (like None, or 1980/0/0 isn't usable.
> We fix this
> with this simple patch, which so far has caused us no problems:
> <snip code allowing empty dates>
> I was told that this had some type of compatibility issue. If thats the
> case, how do you suggest we fix it?
This is something that comes up again and again - perhaps
we should commit to doing something for Zope 2.6.
There are many entries in the Collector with a patch similar
to this, that "works for me". The problem is that you are
changing a semantic that currently deployed production
applications depend on. I, for one, would be quite displeased
if the documented behavior I was depending on in my app
(raising an error if a valid date was not provided) suddenly
changed, probably wreaking havoc on my data integrity.
This is the reason why the "change to converters to accept
empty dates" has never been accepted.
I propose that we could add a new "field type" with a name
like optional_date. The converter handler for that type could
handle an empty field in whatever way we feel is reasonable,
without breaking existing applications. (Let the fight over
"reasonable" begin! :^)
Brian Lloyd [EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -