Hello, As noted by Luke in his review of the time zone support branch, there's a large overlap between django.utils.tzinfo and django.utils.timezone. See the excerpt of our discussion below. I prepared a pull request for this long overdue refactoring.
https://github.com/django/django/pull/1601 There's one known backwards incompatibility, which is also the reason why I initially included a second definition of the local time zone. If you haven't installed pytz, and you're using datetimes before 1970 or 2038, you may encounter exceptions in: - Django's time zone related date formats, specifically "e", "I", "O", "T" and "Z". - the syndications framework — I don't expect blog posts to be dated before 1970 or far into the future, but I suppose the framework could be used for historical data; - the django.utils.tzinfo.LocalTimezone class, which is a public API. In all these cases, the fix is simply to install pytz, and the exception message tells you so (#18766). I believe we'll have to make this change at some point and now seems reasonable. In fact, if you set USE_TZ = True, you're already in the same situation: you need pytz to support datetimes before 1970 or 2038. This hasn't been a problem in practice since Django 1.4 was released. The change I'm proposing here is slightly more disruptive because it may require pytz when upgrading from Django 1.6 to 1.7 even if you don't opt-in to time zone support, but the comparison still stands. Thoughts? -- Aymeric. PS: `pip install pytz` doesn't work with pip 1.4. Use `pip install "pytz > dev"` instead. Questions go to distutils-sig, please :) On 10 nov. 2011, at 01:46, Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote: >> However, my biggest question is about the LocalTimezone class. We now >> have two implementations of this, one in django.utils.tzinfo, which >> seems to have more extensive tests, and a new one in >> django.utils.timezone. The old one is still in use, both by old code >> e.g. in django/contrib/syndication/views.py and new code e.g. >> django/utils/dateformat.py under DateFormat.__init__ >> >> The new one is used in other places. > > Yes. I spent a lot of time on this problem, and I eventually decided > to add a second implementation of the LocalTimezone, because there are > too many issues in the "old" implementation to build more code upon > it. The "new" implementation focuses on correctness and simplicity. > > Here are the problems of the "old" implementation. > > Its __init__ method takes an argument, which is problematic for > pickling and deepcopying. From Python's docs: > >> Special requirement for pickling: A tzinfo subclass must have an __init__() >> method that can be called with no arguments, else it can be pickled but >> possibly not unpickled again. This is a technical requirement that may be >> relaxed in the future. > > Adding a __getinitargs__ method resolved this problem, but it's magic, > and we're still doing something that's officially discouraged. > > Also, I don't like the hack in the "old" implementation to support > post-2037 dates. Sure, it doesn't crash, but it can return wrong data, > because DST doesn't apply during the same period every year. So much > for refusing the temptation to guess in the face of ambiguity :) > > This inaccuracy is irrelevant for syndication (dates are in the past) > and acceptable for display purposes in dateformat (naturaltime will > return "in X years", an offset of 1 hour doesn't matter). But when > we're saving data in the database, we can't take the risk to corrupt > it. > >> Perhaps we just need to combine the two LocalTimezone implementations in >> tzinfo.py? If we can't do that for some backward compatibility reasons, >> can we have some explanation, and preferably a deprecation path for the >> older code? Finally, do we need to address code that uses the old >> LocalTimezone in some way - should it be unconditionally using our own >> LocalTimezone instead of something from pytz when available? > > There are two problems in deprecating the "old" implementation: > - the output of self.tzname() would change — it depends on the > argument taken by __init__; > - post-2037 dates would no longer be supported. > > To sum up: > - the "old" implementation isn't suitable for the needs of my branch; > - there's a lot of history, and we can't deprecate it without creating > regressions: > https://code.djangoproject.com/log/django/trunk/django/utils/tzinfo.py -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
