diff options
author | Joseph Myers <josmyers@redhat.com> | 2024-01-19 13:30:34 +0000 |
---|---|---|
committer | Joseph Myers <josmyers@redhat.com> | 2024-01-19 13:30:34 +0000 |
commit | b86cb494f9a27a106c96c025c6d834334d85b80a (patch) | |
tree | fb2a02011885f7a8c7e0dc7bf4e2740e8b3b617b /io/mkfifo.c | |
parent | 87d921e270acd614077764228881ffcf5e21d9f7 (diff) | |
download | glibc-b86cb494f9a27a106c96c025c6d834334d85b80a.tar.gz glibc-b86cb494f9a27a106c96c025c6d834334d85b80a.tar.xz glibc-b86cb494f9a27a106c96c025c6d834334d85b80a.zip |
Further build-many-glibcs.py fixes for utcnow() deprecation
It turns out that the replacement of datetime.datetime.utcnow(), for a warning produced early in running build-many-glibcs.py with Python 3.12, (a) wasn't complete (there were other uses elsewhere in the script also needing updating) and (b) broke reading of build-time from build-state.json, because an aware datetime was written out including +00:00 for the timezone, which was not expected by the strptime call. Fix the first by making the change to datetime.datetime.now(datetime.timezone.utc) for all the remaining utcnow() calls. Fix the second by using strftime with an explicit format instead of just str() when formatting build times for build-state.json and and email subjects, and then setting the timezone explicitly when reading from build-state.json. (Other uses, in particular messages output by the bot, continue to use str() as the precise format should not matter in those cases; it shouldn't actually matter for email subjects either but it seems a good idea to keep those short.) Tested with a bot-cycle run and checking the format of times in build-state.json afterwards.
Diffstat (limited to 'io/mkfifo.c')
0 files changed, 0 insertions, 0 deletions