Code

Opened 7 years ago

Closed 6 years ago

#3689 closed (fixed)

__year search trouble on 1st of january

Reported by: Dirk Datzert <dummy@…> Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: nesh@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Hi,

I detected in a data_hierarchy filter a strange behavior of dates at 1.1. of a year. I have a field birthday defined as a models.DateField(...). I'm working with a sqlite3 database, python2.5 and django-trunk.

Selecting in the admin view the year say 1990 all dates above 1.1.1990 are selected but not the 1.1.1990 himself.
Maybe this was introduced by the [4505] patch!?

Regards,
Dirk

Attachments (4)

year-search.patch (663 bytes) - added by Dirk Datzert <dummy@…> 7 years ago.
this would fix my problem
sqlite.diff (1.8 KB) - added by Nebojsa Djordjevic <nesh@…> 7 years ago.
patch + tests
sqlite2.diff (2.1 KB) - added by Nebojsa Djordjevic <nesh@…> 7 years ago.
whoops, old patch
sqlite3.diff (2.4 KB) - added by Nebojsa Djordjevic <nesh@…> 7 years ago.
latest ;)

Download all attachments as: .zip

Change History (15)

Changed 7 years ago by Dirk Datzert <dummy@…>

this would fix my problem

comment:1 Changed 7 years ago by Dirk Datzert <dummy@…>

  • Has patch set
  • Needs documentation unset
  • Needs tests set
  • Patch needs improvement unset

comment:2 follow-up: Changed 7 years ago by mtredinnick

  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

I'm pretty sure this is SQLite-specific and we've had similar bugs in the past. The problem is the SQLite does not treat "2007-01-01 00:00:00" the same as "2007-01-01" and we really need to be querying with the latter. Ticket #1460 shows the previous occurrence.

I think the change in this patch should not restrict the change just to the start date. That feels a bit asymmetrical. Shouldn't the final test also be "< (year+1)-01-01" ?

comment:3 Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

  • Cc nesh@… added

comment:4 in reply to: ↑ 2 Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

  • Component changed from Admin interface to Database wrapper

This is not just a admin problem any foo__year query is affected. I hit it today in my non-admin related code.

Replying to mtredinnick:

I think the change in this patch should not restrict the change just to the start date. That feels a bit asymmetrical. Shouldn't the final test also be "< (year+1)-01-01" ?

Here is my stab at this, patch now checks <(year+1)-01-01 and I added some tests also (in tests/regressiontests/datatypes/models.py hope that's OK)

Also, I found another place with 00:00:00 in _sqlite_date_trunc -- should we change this also?

(btw. should I change any of the triage fields after submitting patch?)

Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

patch + tests

Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

whoops, old patch

comment:5 Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

Strange, now I got:

File "/Users/nesh/Documents/workspace/django/tests/modeltests/basic/models.py", line ?, in modeltests.basic.models.__test__.API_TESTS
Failed example:
    Article.objects.filter(pub_date__year=2004)
Expected:
    []
Got:
    [<Article: Area woman programs in Python>]

Looking into it ...

comment:6 Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

Strange, now is OK, maybe probem was with %s-1-1??

I added some future/past checks just to be sure.

Changed 7 years ago by Nebojsa Djordjevic <nesh@…>

latest ;)

comment:7 Changed 7 years ago by ubernostrum

  • Keywords qs-rf added

#5365 was a duplicate.

comment:8 Changed 7 years ago by ubernostrum

See also #5504 which is covering discussion of testing for these cases.

comment:9 Changed 7 years ago by ubernostrum

#6141 was a duplicate and also had some patches.

comment:10 Changed 6 years ago by mtredinnick

  • Keywords qs-rf removed

comment:11 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

(In [7150]) Fixed #3689, #5223 -- Fixed "1st of January" comparisons for SQLite without breaking the other backends.

Based on a patch from raminf and tests from Nebojsa Djordjevic.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.