-
-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use consistent timestamp style #3365
Comments
I've tracked this down. It comes from an inconsistent template tag: @register.filter(name="published_date")
def get_published_date(date):
"""less verbose combo of humanize filters"""
if not date:
return ""
now = timezone.now()
delta = relativedelta(now, date)
if delta.years:
return naturalday(date) # e.g. "Sept 14"
if delta.days: # <= ONLY TRIGGERS IF WITHIN LAST YEAR AND NOT SAME DAY OF MONTH
return naturalday(date, "M j") # e.g. "Sept 14"
return naturaltime(date) # e.g. "an hour ago" The intention of this tag appears to be that if the published date is more than 2 days ago, the actual date is shown, and if it's more recent it says "yesterday" or "4 hours ago" etc. The problem is that if the published date was within the last 12 months it won't have a "year", and if it was the same day of the month it won't have "days". e.g. today is 14 September 2024 by my calendar:
So this is broken both for dates older than a year ago (because it doesn't show a year) and for dates within the last year that are the same day of the month as today. |
Hmm actually older than a year should be fine as it should default to |
Makes all dates fixed except if in the last day, in which case they are relative times. Fixes bookwyrm-social#3365
Bookwyrm inconsistently uses relative dates ("10 months ago") and exact dates ("Jul 4") in the same interface. At a glance, I couldn't tell what order these comments were in. I had to do mental math to know which comment was posted first. Also, hovering the cursor didn't show the full date, which would have helped.
(Now I see that one of them says "started reading" and the other says "finished reading," but that escaped my notice before.)
The solution I'd like
Consistently use relative or absolute dates within an area of the UI, and if a date shown isn't the full date, allow hovering (or tapping on mobile) to see the full date.
Alternatives I've considered
While not my preference, the display could be kept as is but allow hovering/tapping to see the full date.
The text was updated successfully, but these errors were encountered: