Code

Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#443 closed defect (wontfix)

Date's of the form 0000-00-00 don't work

Reported by: mlambert@… Owned by: adrian
Component: Database layer (models, ORM) Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

MySQL uses 0000-00-00 for some dates (as a default for non-null fields, among other things)

This breaks the loader here:

File "django/core/db/typecasts.py", line 8, in typecast_date

return s and datetime.date(*map(int, s.split('-'))) or None # returns None if s is null

ValueError: year is out of range

Perhaps it should just return None instead?

Attachments (0)

Change History (5)

comment:1 Changed 9 years ago by dustin@…

Shouldn't this be a bug filed against mySQL?

comment:2 Changed 9 years ago by adrian

Wait, can you explain this ticket further?

comment:3 Changed 9 years ago by dustin@…

I haven't seen any updates from the submitter, but I can describe it as I see it.

If a date field is NOT NULL in mySQL and you don't have a valid date to insert, you can (or it will) insert 0000-00-00 and return that value when you try to get the date out.

I don't see how this could be considered anything but a bug in mySQL. If you intend to not have valid data for a column, make it nullable.

I don't think Django should be dirtied up to work around a database vendor's belief that the schema should only be followed where it doesn't prevent a user from entering invalid data. (I also don't know why anybody would use mySQL for anything ever, but people do, so I wouldn't hold it against you guys for working around their bugs).

It might be better to recommend that mySQL users configure their DBs to behave correctly. There apparently are options in the mySQL config to at least make it less stupid:

http://dev.mysql.com/doc/mysql/en/server-sql-mode.html

In particular, NO_ZERO_DATE (or better, mode TRADITIONAL -- both as of 5.0.2) will work around this bug in mySQL.

comment:4 Changed 9 years ago by adrian

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

Dustin put it really well: We shouldn't have to clean up MySQL's mess, in this regard. If you're using Django with MySQL, don't use "0000-00-00" for dates.

comment:5 Changed 7 years ago by Jens

Here a small work-a-round patch, that works for me fine:

its for http://code.djangoproject.com/browser/django/trunk/django/db/backends/util.py

@@ -55,6 +55,12 @@
     return datetime.time(int(hour), int(minutes), int(seconds), int(float('.'+microseconds) * 1000000))
 
 def typecast_timestamp(s): # does NOT store time zone information
+    if s.startswith("0000-00-00"):
+        # workaround mysql issue.
+        # see http://code.djangoproject.com/ticket/2763 and 2369
+        # see http://code.djangoproject.com/ticket/443
+        return None
+
     # "2005-07-29 15:48:00.590358-05"
     # "2005-07-29 09:56:00-05"
     if not s: return None

Look at this tickets, too:

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.