Code

Opened 2 years ago

Closed 5 weeks 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

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.

Attachments (0)

Change History (5)

comment:1 Changed 2 years ago by jezdez

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

comment:2 Changed 17 months ago by jairotrad

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

comment:3 Changed 17 months 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 17 months ago by hernantz

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

comment:5 Changed 5 weeks 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].

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.