GenericMappingTools / GenericMappingTools/pygmt
How to handle datetime arrays with timezone information?
- Dominant language
- Python
- Stars
- 874
- Forks
- 255
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 40
Description
_Originally posted by @weiji14 in https://github.com/GenericMappingTools/pygmt/pull/3621#discussion_r1861767477_
> Opening a discussion on whether to:
>
> 1. Follow GMT (allow users to plot data at a non-UTC timezone, by ignoring the timezone offset) [breaking change]
> 2. Follow NumPy, whereby the data will from any non-UTC timezone will be converted to UTC always [current behaviour]
>
> If going with 2, we should at least raise a warning if a non-UTC timezone is used, that a conversion is taking place. If going with 1, we would need to special-case datetime types, that might mean extra logic in the `_to_numpy` function, or having to keep `array_to_datetime` (so don't merge #3507 yet).
| class/type | has timezone support | Link |
|--|--|--|
| Python `datetime` | :white_check_mark: | https://docs.python.org/3/library/datetime.html#datetime.datetime.tzinfo |
| pandas.Timestamp | :white_check_mark: | https://pandas.pydata.org/pandas-docs/version/2.2/reference/api/pandas.Timestamp.html |
| pyarrow.timestamp (type) | :white_check_mark: | https://arrow.apache.org/docs/17.0/python/generated/pyarrow.timestamp.html|
| numpy.datetime64 | :x: | https://numpy.org/doc/2.1/reference/arrays.scalars.html#numpy.datetime64 |
Context is that we need to decide on whether users would expect that datetime arrays/types (e.g. Python `datetime.datetime`, `pandas.Series` with `pandas.Timestamp`, `pyarrow.timestamp`, etc) that have non-UTC timezones should be plotted in the same non-UTC timezone, or have an automated conversion to a UTC timezone before plotting.
Vote :rocket: for option 1, and :eyes: for option 2. Do comment down below to explain.
Contributor guide
Assessment
This issue has not been assessed yet.