Re: usage of TIME_ZONE and zone-to-zone conversion
Hi Shawn, http://pytz.sourceforge.net/ looks like it would be useful for converting time zone strings. The one thing I keep hearing, though, whenever anyone brings up time zones here on django-users is: "*ALWAYS* store dates in UTC, then convert as needed". Don't know how useful that is, but for what it's worth, *whump*, there it is. :) ---Peter Herndon On Apr 27, 2010, at 3:09 PM, Shawn Milochik wrote: > Given a date/time value and a value that is valid for the TIME_ZONE setting > in settings.py, how do I convert that date/time to the time zone defined in > settings.py? > > Example: > settings.py contains: > TIME_ZONE = 'America/New_York' > > Input contains: > date/time value "13:00" > time_zone = "America/Los_Angeles" > > Desired: > timedelta of the +/- difference needed to convert 13:00 PST to > 16:00 EST > > It would be easy to create a dictionary of these values and their UTC offsets > and just use that. But before I potentially reinvent a little wheel, I was > wondering if this conversion was already being handled in Django. > > By looking at the Django codebase I've found the tzinfo file, but it expects > to receive a timedelta as input, and doesn't actually use the TIME_ZONE > value. Further grepping seems to indicate that the string values (such as > 'America/New_York') are only passed to the database engines when creating a > connection object so that the database itself can handle the time zones, and > expects the dates it receives to already have been converted to that zone. > > It appears that the time and datetime Python libraries also use offsets and > US-centric values such as PST and EST for time zones, and not the verbose > names accepted by settings.py and PostgreSQL. > > Thanks, > Shawn > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@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. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Re: usage of TIME_ZONE and zone-to-zone conversion
On Apr 27, 2010, at 3:36 PM, Peter Herndon wrote: > Hi Shawn, > > http://pytz.sourceforge.net/ looks like it would be useful for converting > time zone strings. > > The one thing I keep hearing, though, whenever anyone brings up time zones > here on django-users is: "*ALWAYS* store dates in UTC, then convert as > needed". Don't know how useful that is, but for what it's worth, *whump*, > there it is. :) > > ---Peter Herndon Thanks for the tip on pytz. It might be what I need. As for the other part of your note, I completely agree with the sentiment. The problem is that, in a standard Django installation, there's an inherent timezone defined in settings.py. Given a time from a third party, with a known (different) time zone, it still has to be converted to UTC or the local timezone, and for that I need to be able to derive a timedelta from those verbose time zone names. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Re: usage of TIME_ZONE and zone-to-zone conversion
Thanks for the tip on pytz. It might be what I need. See django-timezones, django-related helpers around pytz: http://github.com/brosner/django-timezones its LocalizedDateTimeField model/form fields construct non-naive python datetimes with pytz tzinfo. (see its tests.py for some additional simple examples) It's basically indispensable for us, even though we really only use one (non-UTC) timezone, just to deal with the idiocy that is DST. As for the other part of your note, I completely agree with the sentiment. > The problem is that, in a standard Django installation, there's > an inherent timezone defined in settings.py. Set django's settings.TIME_ZONE = 'UTC' and work in utc internally*. Seriously. Django will then (try to - watch out for shared apache [1]) set TZ - and will also tell postgresql to expect and return times in utc over the wire (explicitly executes a "SET TIME ZONE" command in the connection). django models.DateTimeFields become "timestamp with time zone" postgresql fields, so your database now uses UTC timestamps that say they are UTC and everything just works. Only now everything's in UTC... so... use django-timezones (django helpers around pytz) to localize user-facing time and accept local time inputs. * Don't use windows on the server, if you are, set the os/system clock to utc too and live with it. [1] http://groups.google.com/group/django-users/msg/6c5e88adfcd2b65f -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
