Include timezone in feed_dates

[dphiffer]

On Slack, snarkout writes:

we’re getting naive dates back from the model, which is mostly fine, the code just doesn’t render a timezone. Is the DB on UTC? The big downside is that there’s no timezone in the RSS pubDate field, which means that a strict parser like the one I’ve been playing with doesn’t render it. I’m happy to change this (for the RSS only) and put up a PR but I wanted to make sure assuming UTC was legit. If you look at the tag on a page, you can see the space where it drops the timezone, e.g. on https://mltshp.com/p/1QLH0

Indeed, looking at the RSS feed, I see e.g. <pubDate>Wed, 04 Dec 2024 00:53:36 </pubDate>. Interestingly we do try to include timezones when formatting the dates, but I suppose since the timezone isn't stored explicitly, the %Z just resolves to an empty string after the time.

This PR replaces all the non-functional %Z with hardcoded UTC.

[bradchoate]

This is happening because the strftime method isn't operating on a datetime instance with time zone information, which is documented behavior.

import datetime
from dateutil.parser import parse
print parse("2024-12-04T21:12:00").strftime("%a, %d %b %Y %H:%M:%S %Z")
print parse("2024-12-04T21:12:00Z").strftime("%a, %d %b %Y %H:%M:%S %Z")

outputs:

Wed, 04 Dec 2024 21:12:00 
Wed, 04 Dec 2024 21:12:00 UTC

I was looking over the RFC822 spec. But it doesn't identify "UTC" in the documentation. "UT", "GMT", "Z", "+0000" are and are equivalent. However, as shown above, "UTC" is output for the "%Z" specifier. That's not to say it is compatible. Some Stackoverflow discussion on this point. I'd probably just use "Z".

Also, please merge from master to bring this branch forward.

[dphiffer]

Thanks @bradchoate that makes sense!

[snark]

Yeah, "Z" or "+0000" are the desired outcomes. It looks like pretty_date operates on the created_at value directly, rather than feeddate, so that should be good as well.

[dphiffer]

I added a new helper, rfc822_date, but it seems like my builds are failing. (Edit: ah, now I see why that build failed, the subsequent commit addresses it, all the same I'd like to be able to test this locally.)

I can only build the containers if I check out the docker-compose-tweaks-redux branch first and then cherry pick the changes in from this branch. When I do that I see a 500 error on the user page template, but nothing gets logged to docker compose logs -f. Grateful for any pointers, and I would not be offended if someone just made their own PR for this instead of trying to help me shave my dev environment yak.

[bradchoate]

Let's remove the comment for the PR reference.

Also, the "Z" I was suggesting earlier was to use a literal Z instead of %Z.

I don't think the parse import is needed, is it? I don't see it being used.

The current build failure is coming from an invalid import of timezone, which doesn't exist for Python 2.

[bradchoate]

You should be able to remove the parse and timezone imports. I'd simplify to:

datetime_format = "%a, %d %b %Y %H:%M:%S"
# If time argument has no timezone information, assume UTC ("Z")
if time.tzinfo == None or time.tzinfo.utcoffset(time) == None:
    format = datetime_format + " Z"
else:
    format = datetime_format + " %Z"
return time.strftime(format)