Allow handling timezone-aware datetime values when inserting or updating - #557
Conversation
947b470 to
48fe6a8
Compare
matriv
left a comment
There was a problem hiding this comment.
LGTM, Left a comment for the changelog
48fe6a8 to
55192cf
Compare
911765c to
e7ad5b5
Compare
mfussenegger
left a comment
There was a problem hiding this comment.
I think it would be worth also extending the data type section in the docs and explain the behavior of datetime with tagged timezone.
One could assume that it persists the timezone information as well, but it's instead converting it to a timestamp with 1970-01-01 as epoch. That's an important distinction
e7ad5b5 to
6c14e44
Compare
| .. NOTE:: | ||
|
|
||
| Values of ``TIMESTAMP`` columns will always be stored using a ``LONG`` type, | ||
| representing the `Unix time`_ (epoch) timestamp, i.e. number of seconds which | ||
| have passed since 00:00:00 UTC on Thursday, 1 January 1970. | ||
|
|
||
| This means, when inserting or updating records using timezone-aware Python | ||
| ``datetime`` objects, timezone information will not be preserved. If you | ||
| need to store it, you will need to use a separate column. |
There was a problem hiding this comment.
@mfussenegger: This paragraph intends to reflect your suggestion. Thank you again, and let me know about any improvements, if you think it could be conveyed better.
-- https://crate-python--557.org.readthedocs.build/en/557/data-types.html
6c14e44 to
f88d10c
Compare
matriv
left a comment
There was a problem hiding this comment.
Thx again, but please wait for @mfussenegger to also check.
| Both when inserting or updating data, values for ``TIMESTAMP`` columns can be obtained | ||
| in different formats. Both literal strings and datetime objects are supported. |
There was a problem hiding this comment.
| Both when inserting or updating data, values for ``TIMESTAMP`` columns can be obtained | |
| in different formats. Both literal strings and datetime objects are supported. | |
| Values for ``TIMESTAMP`` columns can be set as either string literal or datetime object:: |
And then maybe:
"If the datetime object contains timezone information, it is converted to UTC and the timezone information is lost:"
(e.g. do a update returning)
There was a problem hiding this comment.
If it [all three variants] contains timezone information, it is converted to UTC, and the timezone information is discarded.
Text has been changed with 677bef3, thanks.
(e.g. do a update returning)
We may elaborate this on another occasion? I will be all ears to adjust the documentation, in order to improve guidance, but I would need a bit of education first.
| >>> import datetime as dt | ||
| >>> timestamp_full = "2023-06-26T09:24:00.123+02:00" | ||
| >>> timestamp_date = "2023-06-26" | ||
| >>> datetime_aware = dt.datetime.fromisoformat("2023-06-26T09:24:00.123+02:00") | ||
| >>> datetime_naive = dt.datetime.fromisoformat("2023-06-26T09:24:00.123") | ||
| >>> datetime_date = dt.date.fromisoformat("2023-06-26") | ||
| >>> cursor.execute("UPDATE locations SET date=? WHERE name='Cloverleaf'", (timestamp_full, )) | ||
| >>> cursor.execute("UPDATE locations SET date=? WHERE name='Cloverleaf'", (timestamp_date, )) | ||
| >>> cursor.execute("UPDATE locations SET date=? WHERE name='Cloverleaf'", (datetime_aware, )) | ||
| >>> cursor.execute("UPDATE locations SET date=? WHERE name='Cloverleaf'", (datetime_naive, )) | ||
| >>> cursor.execute("UPDATE locations SET date=? WHERE name='Cloverleaf'", (datetime_date, )) |
There was a problem hiding this comment.
If this includes date as well I guess the sentence above should mention that too.
3ebf25d to
677bef3
Compare
|
@mfussenegger: Thanks for your valuable suggestions. 677bef3 bundles all of them into a corresponding fixup commit. |
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
677bef3 to
a494bce
Compare
Problem
As reported at #626, when inserting timezone-aware datetime values, the
CrateJsonEncoderfails withThis patch intends to fix it.
Reference