-----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? 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. 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.
