On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin <[email protected]> wrote: > ... assuming your application is only ever used in one locale. We cannot > make this assumption for all Django applications. > > YYYY-MM-DD is unambiguous and consistent. You could argue that > DD/MM/YYYY is just as good, but Americans tend to interpret it > backwards (they read 10/12/2014 as October 12th instead of December > 10th).
I understand what you're saying, but how is this any different than rendering a date as a string at template time? The Locale needs to be considered in both cases. > > Furthermore, there are two reasons why I'm against making this change > in Django: > - it's a large backwards incompatibility; > - it deviates from Python's behavior in a surprising and unexpected way. Both these concerns could be solved with a setting to turn this feature on and be off by default. What I find surprising is setting a DATE_FORMAT in settings.py has little effect on how many dates are formatted. > If you want that feature, I would suggest to subclass DateTimeField in > your projects. I'll certainly consider this, thanks. But this will not work for any third party apps. It will also mean my apps are not re-usable outside my projects. Cheers, Jon -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b6ozK%3DXi0CceRAujCsQs8eHV5hbH4EWZarmeqs%3DTXkS2A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
