[Zope-dev] Converters.field2date, allow empty string to return None?
Steve Alexander
steve@cat-box.net
Sat, 02 Sep 2000 08:41:51 +0100
Brad Clements wrote:
> One thing that has been bothering me is that I can't easily test my
> ZSQL Methods if they accept a date type unless I completely fill all the
> date arg types.
>
> For example, if the sqlmethod has argument type
> startdate:date=''
>
>
> and in the body I have
> <dtml-if startdate> ...
>
> When i use the test form, I can't leave the date field empty, otherwise I
> get a conversion error from Converters.field2date()
>
> I also have this problem with any form that has type date, if the end-user
> doesn't put a date in the form, I get a conversion error.
>
> Its okay with me to receive an empty string, which gets converted to
> None .. I just put NULL in the sql database.
>
> So .. what's the correct fix to allow empty fields to return either '' or
> None from field2date?
I take the form input as a string, and use an intermediate method that
checks whether it makes a valid date, and massages it into shape if not.
For an empty form field, what is best to do depends on the application.
When I'm using PropertySheets, for example, I often use a boolean
property called "date_is_known". If the date is left blank, I set the
date to 3000-01-01 UTC, and date_is_known to 0. Otherwise, the date gets
set appropriately, and date_is_known is set to 1. I set the date so far
in advance so that if it inadvertantly creeps into some analysis
(because someone forgot to check date_is_known) it will be obvious that
something is up. Of course, this does mean that my systems have a
year-3000 problem. Perhaps I should use 30000 instead? <g>
You can redirect to the form, or an error page, or the form with an
error variable set, if the date is not parsable, or not valid for your
application.
As you're using a SQL database that supports NULL values in date fields,
you can obviiously process the results to mean the same thing.
Oh, if you're just asking people for a date, rather than a date and
time, I'd suggest appending a standard timezone to the date before you
store it. Otherwise, you may have problems with days slipping around if
your server changes timezone or you enter daylight savings time. This is
more of an issue near to the GMT zone.
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net