Opened 4 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 jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 3 years ago by jairotrad

  • Keywords sprint-django-ar added
  • Owner changed from nobody to jairotrad
  • Status changed from new to assigned

comment:3 Changed 3 years ago by jairotrad

  • Owner jairotrad deleted
  • Status changed from assigned to new

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 3 years ago by hernantz

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

comment:5 Changed 2 years ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to 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].

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