Re: Should we require pytz for timezone support in Django?

Would you be comfortable recommending that package for anyone who needs the autodetection? This seems to work: from tzlocal import get_localzone TIME_ZONE = get_localzone().zone What would change compared to the behavior of TIME_ZONE=None is that Django will set os.environ['TZ'] (except on Win

Re: Django ORM query syntax enhancement

Agreed about concatenation functions calls. It would be easy to achieve once filter will accept object-based lookups (previously we discussed expression objects). I think it would be even better to accept objects of expression builder instead (versus expressions directly) - it will separate builder

Re: Should we require pytz for timezone support in Django?

> On 12 Oct 2016, at 18:22, Tim Graham wrote: > > is there some other approach we could take? To obtain the pytz timezone for the local time, you’d need something like: https://github.com/regebro/tzlocal It isn’t exactly straightforward… This approach seems sub-optimal. -- Aymeric. -- You r

Re: Should we require pytz for timezone support in Django?

According to the docs for settings.TIMEZONE: "Django cannot reliably use alternate time zones in a Windows environment. If you’re running Django on Windows, TIME_ZONE must be set to match the system time zone." If we keep supporting setti

Re: Django ORM query syntax enhancement

+1 from me, too. I still think we should be able to get into a point where you can run queries like: Q.user.firstname.collate('fi').lower() == 'anssi' So, not only can you call regular transforms (like lower), but also transforms that take arguments. Other use cases are for example substrin

Re: is_valid as property

Hello Sven, > On 12 Oct 2016, at 12:21, Sven R. Kunze wrote: > > Am Dienstag, 11. Oktober 2016 17:51:20 UTC+2 schrieb Aymeric Augustin: > > The API for displaying errors is form.errors. > > If the documentation implies otherwise, please accept my apologies! > > No problem. I now did read the

Re: is_valid as property

I agree with Tim. I don't think it's overly necessary. FWIW, form.validate actually is form.full_clean. Am Dienstag, 11. Oktober 2016 19:04:51 UTC+2 schrieb Tim Graham: > > I don't think requiring every Django project to rewrite their views from: > > if form.is_valid(): > > to > > form.validate(

Re: is_valid as property

Am Dienstag, 11. Oktober 2016 17:51:20 UTC+2 schrieb Aymeric Augustin: > > On 11 Oct 2016, at 14:52, Sven R. Kunze > > wrote: > > I did never say "let's do business logic in templates". AFAIK, > *displaying* errors (or preparing for it HTML-structure-wise) requires > *knowing* whether a form is