On Fri, Jun 27, 2008 at 5:55 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > > On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > >> All PostgresSQL supports in terms of *storage* is >> a fixedtimezoneoffset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. > > Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the > TIME ZONE! I found it out the hard way yesterday.
Well, it stores the *offset*, which is virtually useless in real-world applications. All PostgreSQL TIMESTAMPs are stored internally as UTC. Since Django does everything with naive datetimes (a *huge* mistake IMHO, and what I'm trying to correct), the Postgres backend stores these in the database as per settings.TIME_ZONE, with that offset. It also retrieves as per that offset, back into naive datetimes. If you change settings.TIME_ZONE, you now get different naive datetimes back with no way to distinguish them. If you want to use multiple time zones at the same time ... good luck, you'll need it. ^_^ Check out the code in Bulbs (The Onion's open source code snippets) for my current crack at this problem; we're about to push a major site live with my "DateTimeZoneField", and I'd love to see something similar make its way into Django: https://launchpad.net/bulbs It could use better documentation, which is on my to-do list as soon as the APIs stabilize a tad. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
