larksuite / larksuite/oapi-sdk-python
DeprecationWarning on Python 3.12+: bundled well_known_types.py uses deprecated datetime.datetime.utcfromtimestamp
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 559
- Forks
- 102
- PR merge metrics
- No merged PRs in 30d
Description
Description
lark_oapi bundles a vendored copy of protobuf's well_known_types.py under lark_oapi/ws/pb/google/protobuf/internal/. That vendored file still calls datetime.datetime.utcfromtimestamp(0), which is deprecated in Python 3.12+ and emits a DeprecationWarning on Python 3.13/3.14:
.../lark_oapi/ws/pb/google/protobuf/internal/well_known_types.py:91: 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).
_EPOCH_DATETIME_NAIVE = datetime.datetime.utcfromtimestamp(0)
Upstream google.protobuf already replaced this call (it now uses datetime.fromtimestamp(0, datetime.timezone.utc)), but the copy pinned inside lark_oapi has not been regenerated, so users on Python 3.12+ still hit the warning whenever the WebSocket (lark_oapi.ws) protobuf code is imported.
Reproduction
Environment:
- Python: 3.14.6
- lark-oapi: 1.7.1 (installed from PyPI; also reproducible against
v2_mainat the path below) - OS: macOS
Steps:
python -W error::DeprecationWarning -c "import lark_oapi.ws.pb.google.protobuf.internal.well_known_types"
Expected: import succeeds with no warning.
Actual:
.../lark_oapi/ws/pb/google/protobuf/internal/well_known_types.py:91: 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).
Location
lark_oapi/ws/pb/google/protobuf/internal/well_known_types.py:91 (still present on v2_main):
_EPOCH_DATETIME_NAIVE = datetime.datetime.utcfromtimestamp(0)
_EPOCH_DATETIME_AWARE = datetime.datetime.fromtimestamp(
0, tz=datetime.timezone.utc)
The _AWARE variant right below already uses the timezone-aware form; only the _NAIVE line needs to change.
Suggested fix
utcfromtimestamp cannot be made timezone-aware directly; replace it with the equivalent naive UTC datetime constructed from the already-correct aware value, e.g.:
_EPOCH_DATETIME_NAIVE = datetime.datetime.fromtimestamp(
0, tz=datetime.timezone.utc).replace(tzinfo=None)
This preserves the original "naive UTC" semantics that callers of _EPOCH_DATETIME_NAIVE rely on (used at line 251: return _EPOCH_DATETIME_NAIVE + delta) while removing the deprecated API call.
Alternatively, regenerate the vendored protobuf stubs from a current googleapis/python-protobuf release so the whole bundled copy tracks upstream fixes.
Impact
- Functional impact: none (warning only; behavior is unchanged).
- DX impact: noisy logs, fails test runs that elevate
DeprecationWarningto errors, and will turn into a hardAttributeErroronce Python removes the API (currently scheduled for a future 3.x release).
Workaround
Users can suppress the warning locally, e.g.:
import warnings
warnings.filterwarnings(
"ignore",
message="datetime.datetime.utcfromtimestamp.*",
category=DeprecationWarning,
)
—but the bundled protobuf code should be updated at the source.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at lark_oapi/ws/pb/google/protobuf/internal/well_known_types.py:91 and compare the naive epoch value with the timezone-aware value immediately below it. Preserve the naive UTC semantics while removing the deprecated call. Run python -W error::DeprecationWarning -c "import lark_oapi.ws.pb.google.protobuf.internal.well_known_types"; done means the import succeeds without a warning.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 88/100