Date validation

[Andrew Bennetts]

On Fri, Apr 25, 2003 at 06:24:51PM +0200, Fredrik Lundh wrote:
> Andrew Bennetts wrote:
> 
> > > > I mean I *could* write this myself, but I had to ask the computer how
> > > > many days in April - someone with a better grasp of the date must have
> > > > written this stuff before :)
> > >
> > > don't you have any knuckles on your left hand?
> >
> > And which knuckles do you use to remember which years are leap years?  ;)
> 
> in what part of the world does the number of days in April
> vary depending on the year?

Heh.  I was pointing out that there's more than just the number of days in a
month involved.  Was 2000 a leap year?  What about 1900?  Dates are just
complex enough that my gut instinct is to avoid writing this sort of code
myself, if I can.  I've no desire to reinvent the mistakes of thousands of
other programmers.

> > > if you want your program to check how many days there are in
> > > a given month, use the calendar module:
> >
> > He does.  In his words: "how can I check whether or not such strings
> > represent a valid date?"
> >
> > His problem is verifying that the entire date is correct.  By the time you
> > factor in the varying days of the months and leap years, I can understand
> > wanting to use a prewritten and tested module rather than an ad-hoc solution
> > for a problem that many people must have encountered before.
> 
> "calendar" is a prewritten and tested module, and has been part
> of Python's standard library since around 1066 AD.

:)

> by using calender, he can add 3-4 lines of obviously correct code
> to his program, and move on to the next problem...

For days in the month, yes, so long as you're willing to ignore leap years.
That's presuming that leap years are the only "gotcha" with date
validation... I might be forgetting something.

Or I might be turning a molehill into a mountain.  But I've far too often
written 3-4 lines of obviously correct code that turned out to be not as
correct as I thought it was :)

If the calendar module had an "isValidDate" function, then I'd be
wholeheartedly agreeing with you!

> in contrast, you're suggesting that he
> 
> 1) update to a newer Python version, and end up with a program
> that may or may not work if run on an older version, or

I didn't suggest that at all; I was merely pointing out that eventually this
annoying problem will be taken care of by the new batteries included in
Python 2.3.  I find people generally like knowing that their problem will be
solved by a newer Python, even if they can't use it just yet.

> 2) backport changes to a newer Python version to his own Python
> install, and end up with a nonstandard Python environment and a
> program that may or may not work if run on an older version, or
> 
> 3) add 550 lines of recently written, rather complex, and yet to be
> widely used code to his application, and end up with a program that
> may or may not work...

At a glance, I thought 2 and 3 were the same option, because the code looked
very similar and was written by the same person.  Thus, I concluded that the
550 lines of code from the recipe were tested -- for better or worse, I
trust the Python standard library to be well-tested and dependable :)

It turns out that the code in 2.3 is a little different; 2.3's _strptime.py
uses the new datetime module in 2.3 to do some of the work -- and in
particular, raise the exception on invalid dates.  So that kills that idea,
because the version in the recipe doesn't raise an exception.

In private email we continued the thread a little, and it looks like he'll
probably use the mxDateTime package, seeing as he was already had it
installed, and it has the behaviour he wants.

> but I can of course not stop him from doing things in the hardest
> possible way; I'm just pointing out that there's another way to solve
> his problem using tools that's already installed on his machine... if
> you have a problem with that, that's your problem.

My problem is that I consider writing code to be a problem :)

If someone else has already written the code, I'd rather use that than my
own effort, if possible.  Sometimes it's too much work to reuse someone
else's code, sometimes it's somehow incompatible with my existing code.
Sometimes it's buggy.  Sometimes I think I could write a better version.

Mostly I just want to get the job done -- in which case I'll quite happily
try someone else's code first before attempting to design, write and debug
my own effort.

> (it could be worse, of course: I'm still waiting for the let's-use-a-
> metaclass crowd to discover this thread...)

No, I'm sure what we *really* need is to use are descriptors that return
generators... <wink>.

-Andrew.