Opened 5 years ago

Closed 2 years ago

#17916 closed New feature (fixed)

humanize naturaltime for large delta

Reported by: anonymous Owned by:
Component: contrib.humanize Version: master
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


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 = 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 Changed 4 years ago by Jannis Leidel

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

comment:2 Changed 4 years ago by jairotrad

Keywords: sprint-django-ar added
Owner: changed from nobody to jairotrad
Status: newassigned

comment:3 Changed 4 years ago by jairotrad

Owner: jairotrad deleted
Status: assignednew

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.

comment:4 Changed 4 years ago by hernantz

Keywords: sprints-django-ar added; sprint-django-ar removed

comment:5 Changed 2 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

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].

Note: See TracTickets for help on using tickets.
Back to Top