Make <time datetime= into valid HTML by using a custom jinja tag

[anorthall]

Status

Ready for review

Description of Changes

Fixes #6057

Change the direct call to __str__() into a call to strftime() to meet the requirement of not having more than 3 decimal places for seconds on HTML. Now, no decimal places are displayed. I decided to implement this instead of the truncate filter as you cannot truncate the datetime object without first converting it to a string.

Testing

Open the website and validate the HTML.

Deployment

No special measures required.

Checklist

• These changes do not require documentation

[cfm]

Thank you, @anorthall! Just a heads-up that this will likely require a rebase after #6041, which moves around the time elements you fix here.

[anorthall]

Thank you, @anorthall! Just a heads-up that this will likely require a rebase after #6041, which moves around the time elements you fix here.

No problem.

[zenmonkeykstop]

Hey, @anorthall, the fix using strftime() looks good - one thing it doesn't account for (and this is an existing problem, not one you added) is formatting of the time values to different locales. If you want to try to support that, the approach I'd suggest would be to:

a) use flask_babel to do the date formatting
b) do the formatting in a custom jinja filter, to make it reusable across the application if necessary (I think there's only one other instance of <time />

In either case, thanks for the PR!

[anorthall]

Hey, @anorthall, the fix using strftime() looks good - one thing it doesn't account for (and this is an existing problem, not one you added) is formatting of the time values to different locales.

Thanks for the tip/info - I will work on this but not until later tomorrow/Thursday at the latest.

[zenmonkeykstop]

Thanks for the tip/info - I will work on this but not until later tomorrow/Thursday at the latest.

No problem, and no rush!

[anorthall]

Hopefully that latest PR will be a better solution. As you can see I added the template tag (html_datetime_format), and I also updated the other location that <time> was used, in the journalist portal.

All tested and working, and the HTML validates.

[cfm]

Test plan

• Open the website and validate the HTML.

In addition:

• Specifically, there are no more Bad value errors on the time[datetime] attributes.
• All instances of the pattern %Y-%m-%d %H:%M:%S%Z have been replaced by the html_format_datetime filter.

Looks good to me, @anorthall! I've left a comment about the localization question, which I've clarified with @zenmonkeykstop; fortunately the solution is just a deletion here and another issue I'll open separately. :-)

Given that there are a couple of iterations recorded in your branch, it would be ideal if you could squash your commits before merge. Or, if you prefer, @zenmonkeykstop can take care of that as the maintainer who will ultimately approve and merge.

[anorthall]

@cfm Changes made and squashed

I note the updater-gui-tests fail is nothing to do with my PR.

[cfm]

Thanks, @anorthall! I confirm that updater-gui-tests is failing without #6069, but since it's irrelevant to your changes here I agree it's not worth rebasing for it.

Tagging @zenmonkeykstop for final approval and merge.

[zenmonkeykstop]

Apologies @anorthall, a rebase gone awry reverted the changes in the PR - I'll fix it momentarily!

[zenmonkeykstop]

Hey @anorthall - I've recovered your changes and resubmitted them in PR #6075 rebased against the origin develop (so CI should pass). Sorry for the mix-up - it looks like the rebase simply overwrote your develop branch with the origin one, the simplest path to recovery was to grab your commit from the reflog and apply them to a new (non-develop) branch on origin.