Fixed #8354: the MySQL backend no longer raises a cryptic error. Instead, it raises a less-cryptic error. Obiously this isn't a perfect solution by any means, but it'll do until we can revisit timezone handling in the future.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8802 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss 2008-09-01 17:48:39 +00:00
parent 15206298ed
commit e545058ba9
2 changed files with 25 additions and 2 deletions

View File

@ -172,15 +172,25 @@ class DatabaseOperations(BaseDatabaseOperations):
return []
def value_to_db_datetime(self, value):
# MySQL doesn't support microseconds
if value is None:
return None
# MySQL doesn't support tz-aware datetimes
if value.tzinfo is not None:
raise ValueError("MySQL backend does not support timezone-aware datetimes.")
# MySQL doesn't support microseconds
return unicode(value.replace(microsecond=0))
def value_to_db_time(self, value):
# MySQL doesn't support microseconds
if value is None:
return None
# MySQL doesn't support tz-aware datetimes
if value.tzinfo is not None:
raise ValueError("MySQL backend does not support timezone-aware datetimes.")
# MySQL doesn't support microseconds
return unicode(value.replace(microsecond=0))
def year_lookup_bounds(self, value):

View File

@ -83,3 +83,16 @@ datetime.datetime(2007, 4, 20, 16, 19, 59)
[]
"""}
# Regression test for #8354: the MySQL backend should raise an error if given
# a timezone-aware datetime object.
if settings.DATABASE_ENGINE == 'mysql':
__test__['API_TESTS'] += """
>>> from django.utils import tzinfo
>>> dt = datetime.datetime(2008, 8, 31, 16, 20, tzinfo=tzinfo.FixedOffset(0))
>>> d = Donut(name='Bear claw', consumed_at=dt)
>>> d.save()
Traceback (most recent call last):
....
ValueError: MySQL backend does not support timezone-aware datetimes.
"""