/django/pull/1327. I'm a git newbie, so it took me
a while to figure out how to remedy that.
I'm not sure if that was why it was getting held up, but it is fixed now.
On Wed, Jul 3, 2013 at 1:19 PM, gilberto dos santos alves
<gsa...@gmail.com>wrote:
> well done.
>
> 2013/7/3 Warre
ct.com/ticket/20693 is ready for somebody to
review it. It would be great if this could get into 1.6.
--
Warren Smith
--
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
+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.
>
>
>
--
Warren Smith
--
django.utils.dateformat.TimeFormat class, similar to the
way they are supported in the DateFormat class, and perhaps do some
refactoring of both classes so that common methods are inherited from an
additional base class.
Thoughts?
Either way, this is worth a ticket so that the idea/problem isn't forgot
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
-managers/
I'm not sure how current this information is, but it is very informative
nonetheless. They all seem to have their strengths and weaknesses.
I guess the choice depends on which functionality is important to you.
--
Warren Smith
--
You received this message because you are subscribed
lution is
> fine, just don't force me to pass everything around as arguments between
> functions. That's not looking likely, but some people here seen to want to
> have that kind of purity at the expense of usability - dammit, Jim, I'm an
> engineer, not a mathematician.
>
>
+1
-
solution to a relatively simple logic problem.
Would it make sense to factor out the connection selection logic into
a utility function with parameters that make it usable in all
contexts, thus yielding a single place to inject the check for the
request-specific default db alias (and perhaps o
>We'd certainly be interested in any
> input on ways to improve usability for the multi-credential case.
>
Excellent. I'll do some experimentation and attempt to come up with
some recommendations.
Thanks. Your brief consideration of this is exactly what I am seeking.
--
Warren Smith
--
branch
have any bearing on this use case?
--
Warren Smith
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@google
"""
Discussion group for issues regarding the development of the Django
framework itself.
For discussion of issues that involve the entire Django community,
including using the
framework to develop applications, please use django-users.
"""
Just my $.02
--
War
11 matches
Mail list logo
