I wonder if the function typecast_date() on /usr/lib/python2.5/site- packages/django/db/backends/util.py:58 assumes the string 's' to be of 'YYYY-MM-DD' format.
Here's the function in question (as of r6460):
def typecast_date(s): return s and datetime.date(*map(int, s.split('-'))) or None
Should the above format be expected, would a sliced 's' be preferable, like this:
def typecast_date(s): return s and datetime.date(*map(int, s[:N].split('-'))) or None
On Sun, 2007-10-07 at 15:30 +0000, jv wrote: > Hello all.
> I wonder if the function typecast_date() on /usr/lib/python2.5/site- > packages/django/db/backends/util.py:58 assumes the string 's' to be of > 'YYYY-MM-DD' format.
> Here's the function in question (as of r6460):
> def typecast_date(s): > return s and datetime.date(*map(int, s.split('-'))) or None
> Should the above format be expected, would a sliced 's' be preferable, > like this:
> def typecast_date(s): > return s and datetime.date(*map(int, s[:N].split('-'))) or None
> Where N could be, e.g., 10.
> What do you think?
Anything is possible, but what is your motivation for the change? Is this another attempt to try and work around the fact that sometimes fractional seconds are given? Or are you trying to pass in data that hasn't been properly sanitised?
Without being able to assess the problem you are trying to solve, it's hard to comment on the change.
> On Sun, 2007-10-07 at 15:30 +0000, jv wrote: > > Hello all.
> > I wonder if the function typecast_date() on /usr/lib/python2.5/site- > > packages/django/db/backends/util.py:58 assumes the string 's' to be of > > 'YYYY-MM-DD' format.
> > Here's the function in question (as of r6460):
> > def typecast_date(s): > > return s and datetime.date(*map(int, s.split('-'))) or None
> > Should the above format be expected, would a sliced 's' be preferable, > > like this:
> > def typecast_date(s): > > return s and datetime.date(*map(int, s[:N].split('-'))) or None
> > Where N could be, e.g., 10.
> > What do you think?
> Anything is possible, but what is your motivation for the change? Is > this another attempt to try and work around the fact that sometimes > fractional seconds are given? Or are you trying to pass in data that > hasn't been properly sanitised?
> Without being able to assess the problem you are trying to solve, it's > hard to comment on the change.
On Sun, 2007-10-07 at 16:02 +0000, jv wrote: > I'm using sqlite3, where dates seem to be saved as bitstrings. So, > when loading a date I get an error like
> ValueError: invalid literal for int() with base 10: > '07T14:07:32.000006'
> The actual date in the DB being
> '2007-10-07T14:07:32.000006'
Right, so it is another one of these "fractional seconds" cases we've been seeing lately. We certainly need to look at these, because there are a number of them floating around at the moment (not sure why there's the sudden influx lately, but that's completely unimportant).
I wouldn't be at all surprised if there's already a ticket open for this issue, so you could have a search in Trac (in the database component) and attach your patch there if there isn't already one available. If you can't find an existing ticket, please do create a new one and attach your patch. I'm not 100% sure that slicing is the right fix here (maybe we can and should preserve the fractional part), but it's certainly a bug at the moment.
Thanks Malcom, I did search and found at least a similar (closed) ticket (#659). Yes, I agree the slicing is a workaround, and does not look like a definite solution at all.
On Oct 7, 12:24 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Sun, 2007-10-07 at 16:02 +0000, jv wrote: > > I'm using sqlite3, where dates seem to be saved as bitstrings. So, > > when loading a date I get an error like
> > ValueError: invalid literal for int() with base 10: > > '07T14:07:32.000006'
> > The actual date in the DB being
> > '2007-10-07T14:07:32.000006'
> Right, so it is another one of these "fractional seconds" cases we've > been seeing lately. We certainly need to look at these, because there > are a number of them floating around at the moment (not sure why there's > the sudden influx lately, but that's completely unimportant).
> I wouldn't be at all surprised if there's already a ticket open for this > issue, so you could have a search in Trac (in the database component) > and attach your patch there if there isn't already one available. If you > can't find an existing ticket, please do create a new one and attach > your patch. I'm not 100% sure that slicing is the right fix here (maybe > we can and should preserve the fractional part), but it's certainly a > bug at the moment.
