Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#23631 closed Bug (fixed)

Documentation: Outdated warning about DateTimeField on MySQL?

Reported by: Kevin Christopher Henry Owned by: nobody
Component: Documentation Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The MySQL Database notes say:

MySQL does not have a timezone-aware column type. If an attempt is made to store a timezone-aware time or datetime to a TimeField or DateTimeField respectively, a ValueError is raised rather than truncating data.

I don't use MySQL so I can't check this, but isn't this wrong? Wasn't this fixed in 1.4 by storing timezone-aware datetimes in UTC? This note goes back to (at least) 1.3, so I'm guessing it was just never updated.

Attachments (1)

23631.diff (692 bytes) - added by Tim Graham 8 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by Tim Graham

Resolution: invalid
Status: newclosed

comment:2 Changed 8 years ago by Kevin Christopher Henry

Resolution: invalid
Status: closednew

But that test class has @override_settings(TIME_ZONE='Africa/Nairobi', USE_TZ=False). When USE_TZ = True the code itself shows that it should work as expected, no?

Changed 8 years ago by Tim Graham

Attachment: 23631.diff added

comment:3 Changed 8 years ago by Tim Graham

Has patch: set
Triage Stage: UnreviewedAccepted

Thanks, I think the attached patch should clarify the situation then?

comment:4 Changed 8 years ago by Kevin Christopher Henry

I think that wording is a little confusing if you're not already familiar with the way timezone-handling works. I would say something like this:

MySQL does not have a timezone-aware column type. When USE_TZ = True and an attempt is made to store a timezone-aware datetime (or time) in a DateTimeField (or TimeField), the datetime is converted to UTC and stored without a timezone. When USE_TZ = False, though, Django chooses to raise a ValueError rather than simply discard the timezone information in the aware datetime.

Either way, though, you should include the same warning for Oracle and SQLite, since they display the same behavior (see here and here).

(Sorry, I'm not able to create an actual patch at the moment.)

comment:5 Changed 8 years ago by Tim Graham

Thanks for the research. In that case, maybe we could just remove the note since the exception that is thrown has a helpful message?

comment:6 Changed 8 years ago by Kevin Christopher Henry

I think that's fine. This note predates Django's timezone support, and the timezone documentation makes pretty clear that correct usage requires a match between USE_TZ and timezone-awareness.

Since this has been inaccurate since version 1.4, hopefully you can backport the deletion...

comment:7 Changed 8 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: newclosed

In 9db3653670d85fbd34cd196b6f4964503c88a5c2:

Fixed #23631 -- Removed outdated note on MySQL timezone support.

Thanks marfire for the report.

comment:8 Changed 8 years ago by Tim Graham <timograham@…>

In 643374bcf544dbcd1091539a9f3c832b5440fee2:

[1.4.x] Fixed #23631 -- Removed outdated note on MySQL timezone support.

Thanks marfire for the report.

Backport of 9db3653670 from master

comment:9 Changed 8 years ago by Tim Graham <timograham@…>

In 625480cf0862f5998ed7e1e324087e58f8a740a7:

[1.7.x] Fixed #23631 -- Removed outdated note on MySQL timezone support.

Thanks marfire for the report.

Backport of 9db3653670 from master

comment:10 Changed 8 years ago by Tim Graham <timograham@…>

In 0a31b4ea8e844f6b2f02027ef4d94b09c34ebb91:

[1.6.x] Fixed #23631 -- Removed outdated note on MySQL timezone support.

Thanks marfire for the report.

Backport of 9db3653670 from master

Note: See TracTickets for help on using tickets.
Back to Top