This filter will display the time as word(s) indicating roughly the time of day ("Morning", "Afternoon", "Evening", etc). For example, the following template snippet:
Posted in the {{ post.date|fuzzy_time }} of {{ post.date|date:"F j, Y"} }}.
will result in the following (assuming `post.date == datetime.datetime(2007, 6, 13, 20, 57, 55, 765000)`):
Posted in the evening of June 13, 2007.
The terms used and breakpoints (hours only) can be rather arbitrary so you may want to adjust them to your liking. See the docs for [bisect][] for help in understanding the code. Just remember you should have one less breakpoint than periods and the first breakpoint falls at the end of the first period. The idea was inspired by [Dunstan Orchard][1], although the code is *very* different (php case statement). He uses quite a bit more periods in a day, so you might want to take a look.
[bisect]: http://docs.python.org/lib/module-bisect.html
[1]: http://www.1976design.com/blog/archive/2004/07/23/redesign-time-presentation/
When saving an edit to an object from a filtered list view you are, by default, returned to list view without any of your filters applied.
This solves that problem, keeping the filtered view in a session variable until you reach a point where the session key is deleted.
This solution doesn't require changes to template code...this is completely self contained within your own admin.py files.
The solution presented here is a revision of a previous patch, which has been modified for Django 1.4. The Django 1.3 version exists at:
http://djangosnippets.org/snippets/2531/
From chronosllc:
The advantage to our solution over the above linked solution is that under different use cases the user may or may not be redirected to the filtered list_view. For example, if you edit an object and click the save and continue button, then you would lose the filter when you finally finished editing the object and clicked save.
Added on here is a delete of the session key when users add objects, the reasoning we're going this route is we don't want to return users to filtered views when they just added a new object. Your mileage may vary and if so, it's easy enough to fit your own needs.
When saving an edit to an object from a filtered list view you are, by default, returned to list view without any of your filters applied.
This solves that problem, keeping the filtered view in a session variable until you reach a point where the session key is deleted.
The solution presented here is hugely based off of other's work with most of the solution gained from:
[Admin: return to change_list with filter and pagination applied](http://djangosnippets.org/snippets/2415/ "Admin: return to change_list with filter and pagination applied")
This solution offered the best approach in our mind over the others listed here on snippets since the solution didn't require changes to template code...this is completely self contained within your own admin.py files.
The advantage to our solution over the above linked solution is that under different use cases the user may or may not be redirected to the filtered list_view. For example, if you edit an object and click the save and continue button, then you would lose the filter when you finally finished editing the object and clicked save.
Added on here is a delete of the session key when users add objects, the reasoning we're going this route is we don't want to return users to filtered views when they just added a new object. Your mileage may vary and if so, it's easy enough to fit your own needs.
HTHs