DRY date_format and datetime objects

[Jon Dufresne]

Hi,

I am using Django 1.6. I find myself using date_format semi-regularly
to convert datetime objects to strings in the DATE_FORMAT format. I
feel like I am repeating myself quite a bit and need to remember to do
this, else I receive the format YYYY-MM-DD, which, in my opinion, is
less pleasant to read.

I am considering a pull request that extends Python's datetime class
that overrides the __str__, __unicode__ methods to always return the
date formatted with the configured DATE_FORMAT. Then all uses
throughout the Django code could use this extended datetime instead of
Python's datetime.

Any thoughts on this? If I do the work, is this something that has a
chance of being accepted?

Cheers,
Jon

[Shai Berger]

Hi,

On Thursday 06 March 2014 23:23:50 Jon Dufresne wrote:
>
> I am using Django 1.6. I find myself using date_format semi-regularly

> to convert datetime objects to strings in the DATE_FORMAT format. [...]

> I am considering a pull request that extends Python's datetime class
> that overrides the __str__, __unicode__ methods to always return the
> date formatted with the configured DATE_FORMAT.
>

> Any thoughts on this? If I do the work, is this something that has a
> chance of being accepted?
>

Can you present your use-case in more detail? Why do you have to format the
dates explicitly in Python code, rather than use the template filter "date"?

Shai.

[Jon Dufresne]

On Sat, Mar 8, 2014 at 6:39 PM, Shai Berger <sh...@platonix.com> wrote:
> Can you present your use-case in more detail? Why do you have to format the
> dates explicitly in Python code, rather than use the template filter "date"?

Sometimes this happens in __unicode__ methods for models. A model may
contain two dates: start and finish. I want the __unicode__ method to
display this range. The method ends up looking like:

def __unicode__(self):
return u'%s (%s–%s)' % (
self.name,
date_format(self.start_date),
date_format(self.end_date))

I use "date_format" so the dates are always formatted correctly and
consistently. I'll sometimes create other utility functions in the
same spirit. With what I'm suggesting, I'd expect to write the
function as:

def __unicode__(self):
return u'%s (%s–%s)' % (
self.name,
self.start_date,
self.end_date)

If the dates always format themselves correctly without me thinking
about it, it seems like and opportunity to stop repeating myself.

Cheers,
Jon

[Aymeric Augustin]

On 9 mars 2014, at 17:41, Jon Dufresne <jon.du...@gmail.com> wrote:

> I use "date_format" so the dates are always formatted correctly and
> consistently.

… 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).

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.

If you want that feature, I would suggest to subclass DateTimeField in
your projects.

--
Aymeric.

[Jon Dufresne]

On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
<aymeric....@polytechnique.org> 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

[Jon Dufresne]

On Sun, Mar 9, 2014 at 10:36 AM, Jon Dufresne <jon.du...@gmail.com> wrote:
> On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
> <aymeric....@polytechnique.org> wrote:
>> 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.

I went back and re-read the documentation on this setting (emphasis mine):

---
<https://docs.djangoproject.com/en/dev/ref/settings/#date-format>

**The default formatting to use for displaying date fields in any part
of the system.** Note that if USE_L10N is set to True, then the
locale-dictated format has higher precedence and will be applied
instead. See allowed date format strings.
---

From my experience this does not seem to be the case. As best I can
tell, it is only the default formatting to use for displaying dates in
templates. When dates are displayed through other means (such as
string formatting), this format sepcification is ignored. This is what
I find confusing and what I hope I could fix.

[Aymeric Augustin]

On 9 mars 2014, at 18:36, Jon Dufresne <jon.du...@gmail.com> wrote:

> 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.

unicode(…) may end up stored in various places such as logs, where the
locale of the original request may not be known. On the contrary, templates
are immediately displayed to an end user.

> Both these concerns could be solved with a setting to turn this
> feature on and be off by default.

If you’ve spent some time on this mailing list, you know that “just
add a setting” isn’t a compelling argument, to say the least…

On 9 mars 2014, at 19:01, Jon Dufresne <jon.du...@gmail.com> wrote:

> As best I can tell, [DATE_FORMAT] is only the default

> formatting to use for displaying dates in
> templates. When dates are displayed through other means (such as
> string formatting), this format sepcification is ignored. This is what
> I find confusing and what I hope I could fix.

I agree, the documentation should clarify that DATE_FORMAT mostly
applies to templates and forms.

--
Aymeric.

[Marc Tamlyn]

Whilst I disagree with the proposed implementation of the ticket, the fact that `DATE_FORMAT` uses a version of formatting (like the date filter[1]) which are actually impossible to duplicate precisely using strftime, it is an irritation when in some cases user facing strings are built in python rather than in the template language.

So I'm against the proposed solution, but I'd like to see some way to more easily format a date to a string in the same way it would be by just writing {{ date }} in a template. If such a utility function exists, it should be better documented.

M

On 9 March 2014 18:52, Aymeric Augustin <aymeric....@polytechnique.org> wrote:

On 9 mars 2014, at 18:36, Jon Dufresne <jon.du...@gmail.com> wrote:

> 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.

unicode(...) may end up stored in various places such as logs, where the

locale of the original request may not be known. On the contrary, templates
are immediately displayed to an end user.

> Both these concerns could be solved with a setting to turn this
> feature on and be off by default.

If you've spent some time on this mailing list, you know that  "just

add a setting" isn't a compelling argument, to say the least...

On 9 mars 2014, at 19:01, Jon Dufresne <jon.du...@gmail.com> wrote:

> As best I can tell, [DATE_FORMAT] is only the default

> formatting to use for displaying dates in
> templates. When dates are displayed through other means (such as
> string formatting), this format sepcification is ignored. This is what
> I find confusing and what I hope I could fix.

I agree, the documentation should clarify that DATE_FORMAT mostly
applies to templates and forms.

--
Aymeric.

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CF3A11BD-EF70-49C8-AA57-90F54C02C796%40polytechnique.org.

For more options, visit https://groups.google.com/d/optout.