Opened 13 years ago
Closed 10 years ago
#17916 closed New feature (fixed)
humanize naturaltime for large delta
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Component: | contrib.humanize | Version: | dev |
Severity: | Normal | Keywords: | sprints-django-ar |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The documentation (for the Django 1.4 development version) states that the naturaltime filter will default to a longer date format if the time delta is greater than 1 day. The code for the naturaltime filter (just checked out from SVN) is as follows:
... now = datetime.now(utc if is_aware(value) else None) if value < now: delta = now - value if delta.days != 0: return pgettext( 'naturaltime', '%(delta)s ago' ) % {'delta': defaultfilters.timesince(value)} elif delta.seconds == 0: return _(u'now') elif delta.seconds < 60: return ungettext( u'a second ago', u'%(count)s seconds ago', delta.seconds ) % {'count': delta.seconds} ...
As can be seen above, if the delta is 1 day or more the value is obtained from timesince which will return a human readable string such as 1 year, 3 months ago (with two time units). If the delta is large, I think it would be better to provide a means to specify the desired date format. I would rather a long date format like 10/3/2012 if the delta is large (rather than 1 month, 2 days ago for example).
Btw I've reported this as a feature but even if this is not implemented I think that the documentation should be updated as it isn't really clear on the format of the fallback date. It simply says "longer date format" which is not clear. I was expecting something like dd/mm/yyyy or something similar.
Change History (5)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Keywords: | sprint-django-ar added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:3 by , 12 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:4 by , 12 years ago
Keywords: | sprints-django-ar added; sprint-django-ar removed |
---|
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I don't think we want to change the behavior, because it isn't obviously wrong and we don't have sufficient reasons to introduce a backwards incompatibility. Indeed, you should implement a custom tag if you have specific requirements not met by Django's native tags.
The documentation issue was previously reported in #16941 and fixed in [07e10fbe9f].
We have been analyzing the case and there is no clear explanation of the API that is required. It looks like this can be achieved with a custom tag.
If someone still believe that this can be implemented a Use case whould be much appreciated.