[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17797402#comment-17797402
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/16/23 11:10 AM:
--------------------------------------------------------------------
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
was (Author: JIRAUSER303038):
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the `datetime_from_utc_to_local` function.
Because of how it converts UTC to local time, it seems that it cannot handle
daylight savings and timezones that have had different UTC offsets in the past
(see comments under [https://stackoverflow.com/a/19238551/9523462).] We can fix
it using `astimezone()`. However, it works as expected only when you run it on
"aware" datetime objects. Aware datetime objects know about their timezone. The
datetime objects that we obtain from the driver are "naive" (see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling `replace()` before calling the `astimezone()`. So, we still need to
keep `datetime_from_utc_to_local` and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests passed (2 tests failed on the clean trunk). Let me
know what you think of it when you find time. Will it help to add unit tests?
Thanks,
Arun
> Modernize CQLSH datetime conversions
> ------------------------------------
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
> Reporter: Brad Schoening
> Assignee: Arun Ganesh
> Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
