> 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] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )