Django actually already adds support for some capabilities to certain database backends, if I'm not mistaken - such as cascades through GFKs on delete.
In terms of time zones, could django "assume"/ensure that the datetime stored in the backend is UTC, then handle the conversion to the local timezone itself? On Jun 1, 9:16 am, VernonCole <vernondc...@gmail.com> wrote: > On May 31, 7:23 am, Daniel Swarbrick <daniel.swarbr...@gmail.com> > wrote:> I can almost hear the collective sigh as this topic once again rears > > up ;-) > > Thanks for bringing it up. I lurk both here and on db-sig, and intend > to use your well done research to once again attempt an update of the > db-api PEP, which also does not address time zone aware time. I like > the idea of standardizing a cross-platform TZ aware data column. > [...] > > > The way I see it, there are a few options for storage of timestamps in > > SQLite (whose docs clearly acknowledge that it does not officially > > support a timestamp column type). > > > 1. Store timestamps as a Unix epoch value (integer). This is fast, and > > will ensure correct date sorting. On the other hand, it's not really > > human-friendly if manually browsing table data in SQLite. > > Not only is the epoch limited in range, I would be wary of using any > storage based on the python time module (as opposed to datetime). We > have discovered enough subtle bugs in the Windows and IronPython > implementations that we gave up trying to get an accurate test of the > python time option on adodbapi. Things that worked correctly for me in > North America would fail for Mark Hammond in Australia. It is a maze > of twisty little passages. We simply recommend that everyone use > datetime. > > On the other hand, I found it necessary to convert date-time values to > ISO format strings in order to feed them to Microsoft ACCESS databases > in some cases, and that works well. But again, as with SQLite, the DB > has no concept of time zones. In the absence of actual time zone > support in the database, any action taken by django is going to > inconvenience somebody, and will likely not be compatible with non- > django use of the same database. Perhaps it would work to store the > pickled tz-aware datetime on brain-damaged databases. But, is it > reasonable to use an application-specific method to extend the > capability of a database engine? > -- > Vernon Cole -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
