On Mon, Jul 1, 2013 at 10:47 PM, Warren Smith <[email protected]> wrote:
> On Fri, Jun 28, 2013 at 5:49 PM, Russell Keith-Magee < > [email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
