Donald Stufft wrote: > I'm very much pro USE_TZ = True being the default.
I very much agree. I've been bitten by a few "can't use naive datetimes" errors as I've been upgrading, but these are easy bugs: they show up when running tests, and are fixed trivially. On the other hand, the kind of bugs that *not* having good timezone support causes are *much* more complicated: email notifications going out at the wrong time, people's credit cards getting billed early or late or not at all, etc. And don't get me started on calendaring. Essentially, without timezones any sort of scheduling functionality is a rats nest of subtle bugs. Adding timezone support exposes these bugs early, and that's a *good thing*. I think of it along the lines of Python 3's new Unicode support: it's a bit of a pain as you learn the new rules, but once you learn them all those run-time "cannot decode/encode" errors go away. Ditto timezones. So yeah, USE_TZ=True in the default project template. But I do think we should have some help for people transitioning -- perhaps a timezone FAQ would be in order? Jacob -- 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.
