Unexpected behaviour when casting time-zone aware datetime to date

[svengiegerich]

Checks

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of Polars.

Reproducible example

from datetime import datetime
from zoneinfo import ZoneInfo

import polars as pl

df = pl.DataFrame({"start": datetime(2021, 1, 1, tzinfo=ZoneInfo("Europe/Berlin"))})

# Correct date (2021-01-01)
print(df.select(pl.col("start").dt.date()).item())

# Incorrect date (2020-12-31)
print(df.select(pl.col("start").cast(pl.Date)).item())

Log output

2021-01-01
2020-12-31

Issue description

When casting a time-zone aware datetime column, the result differs from calling polars.Expr.dt.date().

Expected behavior

I would have expected that the time zone would be respected when casting—i.e., both operations return the same value.

Installed versions

--------Version info---------
Polars:              1.27.1
Index type:          UInt32
Platform:            macOS-15.4-arm64-arm-64bit
Python:              3.12.10 | packaged by conda-forge | (main, Apr 10 2025, 22:19:24) [Clang 18.1.8 ]
LTS CPU:             False

----Optional dependencies----
Azure CLI            <not installed>
adbc_driver_manager  <not installed>
altair               <not installed>
azure.identity       <not installed>
boto3                1.37.1
cloudpickle          3.1.1
connectorx           <not installed>
deltalake            <not installed>
fastexcel            0.13.0
fsspec               2025.3.2
gevent               <not installed>
google.auth          2.39.0
great_tables         <not installed>
matplotlib           3.10.1
numpy                1.26.4
openpyxl             <not installed>
pandas               2.2.3
polars_cloud         <not installed>
pyarrow              19.0.1
pydantic             2.11.3
pyiceberg            0.9.0
sqlalchemy           2.0.40
torch                <not installed>
xlsx2csv             <not installed>
xlsxwriter           <not installed>```

</details>

[MarcoGorelli]

I'm not totally sure about this

If you were to do

import polars as pl
from datetime import datetime
from zoneinfo import ZoneInfo

s = pl.Series([datetime(2020,1,1, tzinfo=ZoneInfo('Asia/Kathmandu'))])

then would you expect it to be time-zone aware, or to keep the underlying timestamp and just convert to the new timezone? Currently, Polars does the latter:

In [4]: s
Out[4]: 
shape: (1,)
Series: '' [datetime[μs, Asia/Kathmandu]]
[
        2020-01-01 00:00:00 +0545
]

In [5]: s.cast(pl.Datetime('us', 'UTC'))
Out[5]: 
shape: (1,)
Series: '' [datetime[μs, UTC]]
[
        2019-12-31 18:15:00 UTC
]

This is also what PyArrow does

In [20]: pc.strftime(arr, '%Y-%m-%d %H:%M:%S %z')
Out[20]:
<pyarrow.lib.StringArray object at 0x761914ac5000>
[
  "2020-01-01 00:00:00.000000 +0545"
]

In [21]: pc.strftime(arr.cast(pa.timestamp('us', 'UTC')), '%Y-%m-%d %H:%M:%S %z')
Out[21]:
<pyarrow.lib.StringArray object at 0x76194e900280>
[
  "2019-12-31 18:15:00.000000 +0000"
]

So what should Polars do when casting to Date (date32)?

• if it were to cast to the local date, that would be inconsistent with what it does for Datetime
• on the other hand, it can't keep the underlying timestamp the same because we're now working in 32 bit integers, not 64 bit ones

PyArrow looks inconsistent here to me, as it casts to the local date:

In [23]: pc.strftime(arr.cast(pa.date32()), '%Y-%m-%d')
Out[23]:
<pyarrow.lib.StringArray object at 0x76190e8ba3e0>
[
  "2020-01-01"
]

I'll try to discuss there before moving forwards here

Arrow issue: apache/arrow#46738