Re: DRY date_format and datetime objects

2014-03-09 Thread 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
wrote:

> On 9 mars 2014, at 18:36, Jon Dufresne  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  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-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.
> 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.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FeypurBk%2BD8rDJQQP710pDM_mpV-37x780r1fjgQVfUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: DRY date_format and datetime objects

2014-03-09 Thread Aymeric Augustin
On 9 mars 2014, at 18:36, Jon Dufresne  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  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-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.
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.


Re: DRY date_format and datetime objects

2014-03-09 Thread Jon Dufresne
On Sun, Mar 9, 2014 at 10:36 AM, Jon Dufresne  wrote:
> On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
>  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):

---


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

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b6V%3DRLm-i6O9U8XUcUh%2BRgdQbZ4ccUNy7JT5LAD3wdymw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: DRY date_format and datetime objects

2014-03-09 Thread Jon Dufresne
On Sun, Mar 9, 2014 at 10:05 AM, Aymeric Augustin
 wrote:
> ... assuming your application is only ever used in one locale. We cannot
> make this assumption for all Django applications.
>
> -MM-DD is unambiguous and consistent. You could argue that
> DD/MM/ 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 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.
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.


Re: DRY date_format and datetime objects

2014-03-09 Thread Aymeric Augustin
On 9 mars 2014, at 17:41, Jon Dufresne  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.

-MM-DD is unambiguous and consistent. You could argue that
DD/MM/ 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.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/66ABF044-6273-4E57-A73D-7FFEA3D9167B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.


Re: DRY date_format and datetime objects

2014-03-09 Thread Jon Dufresne
On Sat, Mar 8, 2014 at 6:39 PM, Shai Berger  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

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4VGaViL0bAGdhdQkCTxoMtbdr7VCYuH1E2UKQp%3D_pCbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: DRY date_format and datetime objects

2014-03-08 Thread 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.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201403090439.39173.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.


DRY date_format and datetime objects

2014-03-06 Thread 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 -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

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b6SE4a1JxfLpdNi415pkuBMYu7rfSP%2BfvWhBNkBDwpE1w%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.