A fix to remove timezone information from dates before inserting in the DB. #16

Open
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
@adamcharnock

A fix to remove timezone information from dates before inserting in the DB.

Some DBs do not support timezones on dates (notably, MySQL). We therefore have to remove the timezone information before storing the value. This is not too bad as we convert to the default timezone in get_db_prep_save(), and add the default timezone information back in get_db_prep_lookup().

I have tried to code this in a way that will be both backwards compatible (no connection parameter in Django < 1.3) and not hard-wired to MySQL specifically.

Of course, if the user changes the default timezone while there is data in the database, it will cause the dates in the database to skew. This is not ideal, but there is not much we can do about this apart from either forcing all dates to be stored in UTC, or putting a suitably large warning somewhere in the docs.

For my part, I wouldn't not mind forcing to UTC, but I am in the UK, so the impact of that for me is probably going to be less.

adamcharnock added some commits Sep 15, 2011

A fix to remove timezone information from dates before inserting in t…
…he DB.


Some DBs do not support timezones on dates (notably, MySQL). We therefore have to remove the timezone information before storing the value. This is not too bad as we convert to the default timezone in `get_db_prep_save()`, and add the default timezone information back in `get_db_prep_lookup()`.

I have tried to code this in a way that will be both backwards compatible (no `connection` parameter in Django < 1.3) and not hard-wired to MySQL specifically.

Of course, if the user changes the default timezone while there is data in the database, it will cause the dates in the database to skew. This is not ideal, but there is not much we can do about this apart from either forcing all dates to be stored in UTC, or putting a suitably large warning somewhere in the docs.

For my part, I wouldn't not mind forcing to UTC, but I am in the UK, so the impact of that for me is probably going to be less.
@paltman

This comment has been minimized.

Show comment Hide comment
@paltman

paltman Sep 24, 2011

This looks like a decent solution. I want Brian Rosner's approval though before I accept as he may have other ideas.

We all use postgresql so haven't experienced this problem before. :)

paltman commented Sep 24, 2011

This looks like a decent solution. I want Brian Rosner's approval though before I accept as he may have other ideas.

We all use postgresql so haven't experienced this problem before. :)

@jezdez

This comment has been minimized.

Show comment Hide comment
@jezdez

jezdez Sep 25, 2012

Contributor

I would argue that this is not needed anymore now that Django has full and transparent support for timezones. django-timezones probably needs to be updated to work in those cases, of course.

Contributor

jezdez commented Sep 25, 2012

I would argue that this is not needed anymore now that Django has full and transparent support for timezones. django-timezones probably needs to be updated to work in those cases, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment