Fix datetime.utcnow() deprecation

[jdavies-st]

This fixes the following deprecation warning:

DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC)

Note that when you pass any timezone to datetime.now(), it returns the offset from UTC (format +HH:MM) appended to the string. The offset from UTC is always zero, and datetime.utcnow() didn't include it. So here it is removed so that timestamps have a consistent format.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (9e7c441) 59.15% compared to head (8b120a0) 59.15%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #134   +/-   ##
=======================================
  Coverage   59.15%   59.15%           
=======================================
  Files          24       24           
  Lines        1611     1611           
=======================================
  Hits          953      953           
  Misses        658      658           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[braingram]

Thanks for making this update! I made a suggestion that should work with python 3.9 to fix the CI.

[braingram]

Suggested change

	datetime.now(UTC)
	datetime.now(timezone.utc)

I believe this and the other suggestion should allow the CI to work with 3.9 and matches the changes made in jwst.

Although not necessary with this PR, would you add a python 3.12 environment to tox and the CI? This would be great to verify that the DeprecationWarning is fixed.

[jdavies-st]

Thanks. Done.

This actually doesn't get picked up in the stpipe unit tests, but does in the jwst unit tests, which test config_parser.py better than stpipe does. One might want to think about adding coverage to the downstream tests, specifically jwst.

[braingram]

Thanks! I totally missed that the lines weren't covered by the unit tests. It might be worth moving some of those over (if that's possible) but that's a problem for another day.

LGTM.

[jdavies-st]

Agree that it would be nice if this package could self-test better. Another day.

I will note that by putting coverage on the downstream test workflows and adding codecov flags, you can keep track separately of which coverage is coming from the package unit tests and how well the downstream packages test it. But currently the OpenAstronomy CI workflows don't support specifying codecov flags, though it would be easy enough to add probably. Flags are used in the jwst package Jenkins regtests currently, though the unit test flags disappeared with the switch to OpenAstronomy CI workflows.