models.TimeField has no to_python method
Sean Legassick
Hi,
Before I raise a ticket about this I wanted to check I'm not missing
something or being otherwise stupid: is there a good reason why
TimeField doesn't have a to_python method to coerce values to
datetime.time objects?
Thanks,
Sean
--
Sean Legassick
sean.le...@gmail.com
Leo Soto M.
<sean.le...@gmail.com> wrote:
>
>
> Hi,
>
> Before I raise a ticket about this I wanted to check I'm not missing
> something or being otherwise stupid: is there a good reason why
> TimeField doesn't have a to_python method to coerce values to
> datetime.time objects?
I'm not going to pretend that I know why there is not
TimeField.to_python. But some changes on #7560 needed it, so it is
implemented on its attached patch.
--
Leo Soto M.
http://blog.leosoto.com
Sean Legassick
On 22 Jul 2008, at 15:01, Leo Soto M. wrote:
> I'm not going to pretend that I know why there is not
> TimeField.to_python. But some changes on #7560 needed it, so it is
> implemented on its attached patch.
Ah yes, so it is.
Anything I can do to help? (I do a lot of development with the gis
branch and PostGIS so I can try out the patch there and see what
happens).
--
Sean Legassick
sean.le...@gmail.com
Leo Soto M.
That'd be very useful!
I've done extensive testing of #7560 with all the official backends,
but haven't found the time to also include the gis branch as part of
my testing process.
Sean Legassick
On 22 Jul 2008, at 17:13, Leo Soto M. wrote:
>> Anything I can do to help? (I do a lot of development with the gis
>> branch and PostGIS so I can try out the patch there and see what
>> happens).
>
> That'd be very useful!
>
> I've done extensive testing of #7560 with all the official backends,
> but haven't found the time to also include the gis branch as part of
> my testing process.
The patch applies cleanly to gis HEAD, tests all pass (or at least the
same tests fail as gis and those are in unrelated areas), and my own
app runs fine (these are all just PostGIS tests - I don't have Oracle
but if I get a free moment I will try and setup a MySQL + spatial
extensions environment to test with too).
I did however spot a couple of minor bugs in the implementation of
TimeField.to_python (the fallback to '%H:%S' format parsing was
constructing a datetime.datetime object instead of a datetime.time
object and the slice on the same line was wrong).
I've uploaded a new patch to the ticket with those bugs fixed, and
I've also added some TimeField testing to tests/modeltests/validation
which test for a functional TimeField.to_python method.
--
Sean Legassick
sean.le...@gmail.com
Leo Soto M.
<sean.le...@gmail.com> wrote:
> On 22 Jul 2008, at 17:13, Leo Soto M. wrote:
> >
> > > Anything I can do to help? (I do a lot of development with the gis
> > > branch and PostGIS so I can try out the patch there and see what
> > > happens).
> >
> > That'd be very useful!
> >
> > I've done extensive testing of #7560 with all the official backends,
> > but haven't found the time to also include the gis branch as part of
> > my testing process.
>
> The patch applies cleanly to gis HEAD, tests all pass (or at least the
> same tests fail as gis and those are in unrelated areas), and my own
> app runs fine (these are all just PostGIS tests - I don't have Oracle
> but if I get a free moment I will try and setup a MySQL + spatial
> extensions environment to test with too).
>
> I did however spot a couple of minor bugs in the implementation of
> TimeField.to_python (the fallback to '%H:%S' format parsing was
> constructing a datetime.datetime object instead of a datetime.time
> object and the slice on the same line was wrong).
Oops. Brain failure from my part.
> I've uploaded a new patch to the ticket with those bugs fixed, and
> I've also added some TimeField testing to tests/modeltests/validation
> which test for a functional TimeField.to_python method.
Cool, I think that's why is so good to have many eyes looking at the
source code (and have the source code available in the first place :-)