> http://collector.zope.org/Zope/30
> What are people take on empty dates?
> <snip>
> 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 - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to