On Monday, February 20, 2012 at 4:24 PM, Carl Meyer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/20/2012 01:59 PM, Aymeric Augustin wrote: > > The main reason for enabling time zone support by default in new > > projects (through the settings.py template) was to store UTC in the > > database (on SQLite, MySQL and Oracle; PostgreSQL always does that > > anyway). > > > > This decision was certainly skewed by my background in enterprise > > software, where reliable handling of datetimes is a no brainer. But > > this isn't the most common use case for Django. > > > > Python doesn't make it very easy to deal with time zones, so forcing > > that concept on developers isn't friendly. The "right way" to do > > things is impractical, and there isn't that much space for > > improvement. > > > > > Can you give more specifics here? Exactly how much harder is it to work > with USE_TZ = True than USE_TZ = False for a new Django developer, > presuming they don't really care about timezones at this point and just > want to do things more or less right so as not to box themselves in a > corner if they want to add real timezone support in the future? > >
In my experience with using Django 1.4a1, and now 1.4b1 with USE_TZ=True it has not been difficult. The biggest hurdle is that when generating a date/time programmatically you need to make sure to attach a timezone to it. With pytz this is pretty easy. ``datetime.datetime().replace(<PYTZ Timezone>)`` instead of just ``datetime.datetime()``. Really the biggest hurdle I had in using 1.4 with USE_TZ = True is that libraries I don't control tend to use date/times without a timezone attached causing an exception. I would argue that this is a benefit rather than a negative though as otherwise you just kind of assume that those other libraries are using the same timezone as you (``datetime.datetime.now vs date time.datetime.utcnow vs datetime's coming from another source in any other timezone``). And I feel like my code has less of a chance for silent data corruption now that I am no longer just assuming that libraries are using the same timezone as me and I explicitly attach a timezones to the incoming date/times asap. > > I guess I think there's some value in setting people on the right path > earlier rather than later, but it really depends on exactly how much > harder that path is. > > Carl > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9CugQACgkQ8W4rlRKtE2fr6wCg2/cXMn/bHL/p6Cg5YDzZmPNe > AasAoKWeKEnDnWvcuYZR3EsqRsMlRfnB > =Sjc9 > -----END PGP SIGNATURE----- > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
