> On 09 Oct 2016, at 20:09, Kevin Brown <ke...@kevinbrown.in
> If there was interest in dropping support for using Django without timezones (so removing USE_TZ = False), then I would understand the push for making pytz required for everyone.
You’re making the assumption that pytz is only needed when USE_TZ = True. In practice it isn’t that simple.
If you look at Tim’s patch you’ll see that code that relies pytz doesn’t look like `if settings.USE_TZ: # do something with pytz` in general. Several APIs need to account for time zones to produce accurate results even when USE_TZ = False, for example, if memory serves, template tags that humanize durations, probably others. Also django.utils.timezone can be useful even when USE_TZ = False.
The patch makes it clear that managing with / without pytz alternatives everywhere creates a lot of noise and a lot of error messages that boil down to “yeah, this doesn’t work without pytz, install it”. Forcing the install upfront has a negligible cost and removes the possibility to hit these frustrating errors
Also supporting two code paths cause a non-negligible overhead for the development of Django. Every time someone wants to add a test that involves datetimes, they have to figure out what happens with or without pytz, whether the test should be skipped and in which circumstances, etc. Often, I still have to intervene myself, even though it’s been four years since I added time zone support to Django. The developer experience in this area is awful :-/
Of course the point of Django is to have few people make efforts so that everyone else doesn’t have to, but in this case, the burden added on everyone else seems barely noticeable. If the concern is the size of a Django install, honestly, there are other areas to target (e.g. ship contrib apps, translations, etc. separately).
I hope this clarifies the situation,