Import of dateutil.parser causing DeprecationWarning on Python 3.12

[kbakk]

Describe the bug

When importing jsii in Python 3.12, and specifying to raise warnings as error (normally done as part of testing, not in production), you'll get a deprecation warning raised from dateutil.parser:

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

Expected Behavior

No deprecation warnings raised when using jsii

Current Behavior

Python raises warning

Reproduction Steps

Install jsii with Python 3.12. Then run:

python -W error -c 'import jsii'

Output:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/__init__.py", line 5, in <module>
    from ._runtime import (
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/_runtime.py", line 20, in <module>
    from . import _reference_map
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/_reference_map.py", line 5, in <module>
    from ._kernel.types import ObjRef
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/_kernel/__init__.py", line 16, in <module>
    from .providers import BaseProvider, ProcessProvider
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/_kernel/providers/__init__.py", line 2, in <module>
    from .process import ProcessProvider
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/jsii/_kernel/providers/process.py", line 20, in <module>
    import dateutil.parser
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/dateutil/parser/__init__.py", line 2, in <module>
    from ._parser import parse, parser, parserinfo, ParserError
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/dateutil/parser/_parser.py", line 50, in <module>
    from .. import tz
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/dateutil/tz/__init__.py", line 2, in <module>
    from .tz import *
  File "/private/tmp/repro-jsii/venv/lib/python3.12/site-packages/dateutil/tz/tz.py", line 37, in <module>
    EPOCH = datetime.datetime.utcfromtimestamp(0)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).

Possible Solution

jsii depends on dateutil.parser.isoparse (docs) to parse $jsii.date:

jsii/packages/@jsii/python-runtime/src/jsii/_kernel/providers/process.py

Line 133 in 62d2d37

return dateutil.parser.isoparse(d["$jsii.date"])

This is the only use of dateutil. Also, dateutil hasn't been updated since July 2021.

Based on this doc it seems to be a fixed format being parsed, i.e. no need to use a parser that handles different formats:

jsii/gh-pages/content/specification/2-type-system.md

Lines 229 to 241 in 62d2d37

	### Date Serialization
	[date]: #date-serialization
	JSON has no standard expression for `Date`. A special JSON object representation is used to allow unambiguously
	conveying a date. The wrapper has a single key (`$jsii.date`) with the [ISO 8601-1] UTC representation of the `Date`
	value:
	```json
	{ "$jsii.date": "2020-01-20T14:04:00.000Z" }
	```
	[iso 8601-1]: https://www.iso.org/obp/ui#iso:std:iso:8601:-1:ed-1:v1:en

So dateutil.parser could potentially be removed as a dependency, and replaced with the standard library datetime.datetime.strptime method.

Additional Information/Context

No response

SDK version used

jsii 1.94.0

Environment details (OS name and version, etc.)

MacOS, Python 3.12.0

[kbakk]

A release of dateutil (2.9.0) have addressed this issue, so by upgrading to >=2.9.0 the issue is no more.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.