On Mon, Nov 19, 2012 at 2:29 PM, Tom Evans <tevans...@googlemail.com> wrote: > On Fri, Nov 16, 2012 at 5:50 PM, Sencha <mich...@d3i.com> wrote: >> Yes I'm aware of this, however I'm not generating the datetime objects, it's >> all coming from Django (hence me wondering whether or not it's a bug or >> not). All I need to do to replicate the bug is get the object from the db >> and then save is straight away; then warning appears. >> >> Django abstracts away the difference between MySQL's datetime field and >> timestamp field, so it should work! >> > > Oh really? How have you determined that django is producing the naive > datetime? This is a loaded question, since I know django does not > produce naive datetimes when USE_TZ=True! See the end of the email for > the easiest way to determine where the naive datetime is actually > coming from.
Write in haste, repent at leisure :/ I'm almost certainly wrong here. The issue is that (apart from me not being able to read) is in two parts. Firstly, TIMESTAMP field in MySQL has no TZ info associated with it - MySQL will always convert a TIMESTAMP field to UTC, and return it as UTC, and secondly, Django has no understanding of a TIMESTAMP field, and so doesn't have semantics to cope with it being returned in UTC. You can't store an aware datetime in a TIMESTAMP, because it will always lose it's tzinfo, and will be UTC when extracted, so it isn't suitable for use with TZ aware datetimes. If the TZ itself isn't important, but keeping it as a TIMESTAMP is (presumably for auto updating?), I would subclass DateTimeField so that it 'fixes up' non aware datetimes as extracted from the DB to UTC. Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
