[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