On Fri, Jun 28, 2013 at 5:33 AM, Warren Smith <[email protected]> wrote:
> Is anyone aware of a reason why the built-in time template filter does not
> have timezone support? The built-in date template filter has timezone
> support, but I wanting to use the TIME_FORMAT default stuff linked to the
> time filter.
>
> Was timezone considered to be not relevant for the time filter? I found
> the bit in the Time Zone documentation about Django only supporting naive
> datetime.time objects, so I suppose this might have been the justification
> for not supporting timezones in the time filter. However, the time filter
> can be applied to datetime.datetime objects as well, to display only the
> time portion. That might even be the most common use case. It is at least
> my use case. In that context, I would think the timezone IS relevant.
>
> What I'm wanting to be able to do is set settings.TIME_FORMAT = 'g:i a T'
> and then use <datetime_var>|time in my templates to get times with
> timezones at the end.
>
> I would prefer not to have to resort to a custom filter for what seems to
> be very generic behavior. What am I doing wrong?
>
Hi Warren,
I can see how what you're describing is a problem, and as far as I can make
out, you haven't missed anything.
The issue is how to handle the ambiguity it introduces; Django has punted
on the problem because what you're describing is an edge case with some
ambiguity, and there are ways to work around the problem.
The problem with datetime.time is that time objects *can't* have a timezone
-- at least, not reliably. For example - If your timezone is EST, and the
time is 10:00 UTC - what time is it in EST? You can't answer that question
reliably because it might be 0500, or it might be 0600, depending on the
date. Although common vernacular often describes the timezone as EST and
EDT, there's actually only one timezone, and part of that timezone
definition is the rules for switching for switching forward and back the
extra hour. Without a date associated with the time, timezone calculations
are error-prone at best.
As a result, since the default usage of |time is on time objects, the
implementation of the time filter doesn't support the use of the T format
specifier.
However, you *can* use exclusively time-related format specifiers in the
date filter; for example:
{{ mydatetime|date:"g:i a T" }}
will work and give you the output you expect, and if you set
DATETIME_FORMAT to "g:i A T", you'll get all datetimes displayed in the
format you describe. The problem is that *all* datetimes will be displayed
like that by default, and you won't ever see the actual date printed.
So - short term, the fix is to use an explicit format string wherever you
want this behaviour. Yes, it's annoying that you can't just set a default,
but it works. Defining a custom filter that implements the default could be
done in about 5 lines of code (including tag registration) if the
repetition of the format string bugs you enough. You can even call that
filter |time if you want - Django's template engine takes the 'newest' tag
registration as the canonical one, so you can overwrite system-provided
tags.
Longer term, I can see that there is something we could address - the
question is how.
What you've described is the ability to set TIME_FORMAT to a value that
won't be valid for the default case (using time objects on the time
filter), so we'd need to come up with an interpretation for how to ignore T
(and any other timezone-sensitive format values) when it can't be used. I'm
not sure how I feel about ignoring formatters as an approach -- my gut
reaction is that it's a bad idea, but I can see how it *might* work.
Another approach might be to make |time call on the |date format - however,
this means you would need to set DATETIME_FORMAT
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.
If you've got any other ideas, I'd be interested in hearing them. Either
way, this is worth a ticket so that the idea/problem isn't forgotten.
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.
