Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2020-10-21.19:51:20.376>created_at=<Date2017-04-24.15:27:26.203>labels= ['expert-C-API', 'type-feature', 'library', '3.10']
title='Add ability to get tzinfo from a datetime instance in C API'updated_at=<Date2020-10-21.19:51:20.376>user='https://bugs.python.org/atuining'
Right now there is no documented way to create a datetime instance with a tzinfo instance. The documented macros all hard code the value Py_None for the tzinfo parameter. Using the PyObject_Call() method instead of the macro for creating a datetime instance is ~5x slower.
In addition, there is no macro or method for getting the tzinfo from an existing datetime instance. Perhaps creating DATE_GET_TZINFO and TIME_GET_TZINFO would be acceptable?
Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation.
I agree that it should be possible to construct TZ-aware datetimes using the official C API, so I guess the question is whether to add a bunch more macros or document the existing struct.
An official accessor for the tzinfo component of an existing datetime, which I think is very reasonable in light of the fact that there are official accessors for all the other components of a datetime.
An official constructor for a timezone-aware datetime, which I think basically exists in the form of PyDatetime_CAPI->PyDateTimeAPI->DateTime_FromDateAndTime / ->DateTime_FromDateAndTimeAndFold, and we just need to document it. I think this is basically a separate issue, and I have opened bpo-39604 to track it.
I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them:
Please make sure to add tests to any PR you make. See the CapiTest case (
) for examples. You may want to look at the git blame for a few of those tests to see the PRs that they were added in, since part of the tests are defined in a C file.
(As an aside: I don't love that the accessor methods are not available on the struct, since all the "macro-only" code needs to be re-implemented in all other-language bindings. Since the accessors are already all macro-only, though, might as well keep with the tradition for now :P)