You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by "Fokko (via GitHub)" <gi...@apache.org> on 2023/03/08 19:24:09 UTC
[GitHub] [iceberg] Fokko commented on pull request #6879: Python: Liberal Timestamp parsing
Fokko commented on PR #6879:
URL: https://github.com/apache/iceberg/pull/6879#issuecomment-1460732865
> We could add a "session time zone" like SQL and use that when it isn't specified. We can then default the session time zone to UTC
That would work for me. We could set this as a property in the configuration.
> We could make helper methods for creating time literals, like `timestamp(iso8601: str, defaultZone: str = "+00:00") -> int` that make it clear what is happening by having a defined default
I'm less in favor of this one because I think this is mostly around the filter API;
Instead of:
```python
tbl.scan(
row_filter=GreaterThanOrEqual("tpep_pickup_datetime", "2022-01-01T00:00:00+00:00")
).to_arrow()
```
Have the API As:
```python
tbl.scan(
row_filter="tpep_pickup_datetime >= '2022-01-01T00:00:00+00:00'"
).to_arrow()
```
Then it is easy to forget the `+00:00` and then a user would need to look up the format which is not very user-friendly. A logical evolution is also:
```python
tbl.scan(
row_filter="tpep_pickup_datetime >= '2022-01-01'")
).to_arrow()
```
Where `tpep_pickup_datetime` is a datetime. Setting a timezone on a date would also be a bit awkward.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org