On Mon, Jul 1, 2013 at 10:47 PM, Warren Smith <wsmith...@gmail.com> wrote:
> On Fri, Jun 28, 2013 at 5:49 PM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> >> A third approach would be a new setting, for AWARE_TIME_FORMAT that would >>>> only get used if you pass a datetime object to |time; this *would* be able >>>> to use T as an option. However, this means introducing a new setting, which >>>> is rarely a good answer to a problem. >>>> >>> >>> Agreed. Adding new settings == generally bad. Explaining why we need the >>> new setting == fairly hard. Hard to explain == bad idea. >>> >> >> I don't think it's *that* hard to explain - one is a format that will be >> used for naive time objects; one is a format that will be used for >> timezone-aware time objects (primarily datetimes). >> >> However, given that there's precedent for blanking formats when they >> don't/can't apply, that would appear to be the better solution. >> >> > Agreed. > > Also, just to clarify, I think we should stick with Django's policy of > only supporting naive time objects, for the reasons you cited earlier in > this thread. > > So, any timezone support we would add to the time filter should only > support aware datetime objects, not aware time objects. > > Correct? > Yes - that sounds like the right approach to me. Yours, Russ Magee %-) -- 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. For more options, visit https://groups.google.com/groups/opt_out.
