fix: handle deprecation of datetime.utcnow()

[agoose77]

I saw this warning in the logging of another PR.

I have not been able to test this locally (or rather, I didn't want to spin up a minikube cluster).

Hopefully the CI catches any regressions.

[minrk]

the +Z here works for adding the UTC timezone indicator to a naïve datetime, but now_utc is now a tz-aware datetime, so this produces:

2025-01-23T08:33:01.361903+00:00Z

We can do one of:

1. use isoformat as-is with the new tz-aware datetime and stop adding the Z (+00:00 is equally valid, if not as common for always-utc machine timestamps)
2. use `.isoformat().replace("+00:00", "Z")
3. keep now_utc as naïve by adding .replace(tzinfo=None) to its construction
4. use strftime('%Y-%m-%dT%H:%M:%SZ') to explicitly format with Z instead of utc offset

I don't really have a preference, so whichever strikes your fancy. I guess the simplest and most consistent with before is option 3.

[agoose77]

@minrk huh, good spot! I didn't see that utc_now was already tz aware.

I like your presentation of the options. My preference is for (4), as it explicitly defines the spec that we're formatting for the recipients, and doesn't break anyone already relying on the format of the timestamp.

[rgaiacs]

I think option 4 is better to backward compatibility. I'm also happy with option 3.

[agoose77]

I've made the change, and restored microseconds.

[minrk]

Thanks!