fix: use timezone-aware datetimes in expiry calculation

[tonyandrewmeyer]

Summary

• _calculate_expiry() (line 539): Changed datetime.datetime.now() to datetime.datetime.now(tz=datetime.timezone.utc) so that when a charm passes a timedelta for secret expiry, the resulting datetime is timezone-aware. Previously, the naive datetime would be serialised via datetime_to_rfc3339 (which calls .isoformat()), producing a string without a timezone suffix. Juju expects RFC 3339 timestamps with timezone information.

• Container._build_fileinfo() (line 3047): Changed datetime.datetime.fromtimestamp(info.st_mtime) to datetime.datetime.fromtimestamp(info.st_mtime, tz=datetime.timezone.utc) so that FileInfo.last_modified carries UTC timezone information rather than being a naive datetime in the local timezone.

Both fixes ensure that datetimes produced by these functions include explicit UTC timezone data, which is necessary for correct RFC 3339 serialisation and consistent behaviour across different host timezone configurations.

🤖 Generated with Claude Code but owned by me.

[james-garner-canonical]

The _calculate_expiry change seems correct.

Does this fix an active bug or one that we'd hit with a future Juju release? The PR description isn't clear, e.g.

Juju expects RFC 3339 timestamps with timezone information.

Implies that our timezone-naive timezones might be being rejected or treated oddly by Juju (perhaps it treats timestamps without timezone info as UTC, which will be incorrect in most timezones?).

---

The _build_fileinfo change appears to be a no-op (see comment), but is more correct, so that one doesn't need discussion.

[dimaqq]

The change looks solid.

I'm curious how come this was not an issue until now.

Also, please validate that some old Juju, like 2.9.x honours the new timestamps. I'd assume that Juju did from the get-go, being coded in Go, but better safe than sorry.

[tonyandrewmeyer]

Also, please validate that some old Juju, like 2.9.x honours the new timestamps. I'd assume that Juju did from the get-go, being coded in Go, but better safe than sorry.

The change is in secrets, which aren't in 2.9, so that's not something that can be validated. (The other case was internal Ops code, but has been removed as suggested elsewhere in the PR).