fix: display document expiration notification in UTC#6600
Conversation
The document expiration mail displays the date of the upcoming document expiration, but different timezones makes that date ambituous. Instead, clearly show that as a timestamp in UTC. Fixes ietf-tools#1825
Two templates seem related to the expiration notifications, but they aren't actually used. Get rid of them.
Codecov Report
@@ Coverage Diff @@
## main #6600 +/- ##
==========================================
+ Coverage 88.85% 88.86% +0.01%
==========================================
Files 284 284
Lines 40253 40275 +22
==========================================
+ Hits 35765 35791 +26
+ Misses 4488 4484 -4
|
rjsparks
changed the title
|
@meadmaker - please start using this for your commit messages: https://www.conventionalcommits.org/en/v1.0.0/ |
There was a problem hiding this comment.
Requesting a minor code cleanup as noted inline.
I also want to point out to @rjsparks that this will change the deadline from a tz-naive date to the UTC datetime describing midnight Pacific time. That was what I suggested as my best guess as the way to do things.
Thinking about it now, I think it'll be midnight at the start of the doc.expires date, which might be incorrect. Maybe it needs to be +datetime.timedelta(days=1).
ietf/doc/expire.py
Outdated
| DEADLINE_TZINFO | ||
| ).replace( | ||
| hour=0, minute=0, second=0, microsecond=0 | ||
| ).astimezone( |
There was a problem hiding this comment.
Don't actually need to convert the timezone to UTC - the |utc in the template will do the right thing (also, just as a non-obvious fyi, we're trying to use datetime.timezone.utc as the UTC zone rather than ZoneInfo("UTC") or any of the various other synonyms)
|
@larseggert - Can we by fiat declare draft expiration happens at UTC midnight, or do we need more process first? |
|
I think IESG can declare. How easy would it be to do "anywhere on Earth"? |
|
Anywhere on earth essentially means "international date line" instead of "Greenwich Meridian". It is easy to do, but it runs counter to the previous expressed goal to do everything in UTC. |
|
On 2023-11-06, at 11:11, Jennifer Richards ***@***.***> wrote:
Thinking about it now, I think it'll be midnight at the start of the doc.expires date, which might be incorrect. Maybe it needs to be +datetime.timedelta(days=1).
This.
If my driving license expires on 2023-12-24, I expect still to be able to drive on 2023-12-24.
Grüße, Carsten
|
|
My takeaways here are:
I'm going to go work on that, and submit it to this issue. I'm going to look for opportunities to make the expiration of documents more explicit, though - we've already found at least six reasonable interpretations for when that could be (beginning of date and end of date, crossed with PDT, UTC, and International Dateline). I wonder whether it would be better to convert the |
I should have said I just examined the |
The document expiration mail displays the date of the upcoming document expiration, but different timezones makes that date ambituous. Instead, clearly show that as a timestamp in UTC.
Fixes #1825