Skip to content

Conversation

@RoosSchellevis
Copy link
Contributor

@RoosSchellevis RoosSchellevis commented Nov 19, 2025

Added functionality to ensure timezones are retained from input profiles.
Tested both the array and df input options, adjusted error handling when incorrect data is provided for dates.

fixes #118

if isinstance(obj, pd.DatetimeIndex) and obj.tz is not None:
# tz-aware: preserve original timezone
return np.array(obj.to_pydatetime(), dtype=object)
return obj.to_numpy(dtype="datetime64[ns]")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For which types do you want this return to happen?

if isinstance(obj, pd.DatetimeIndex) and obj.tz is not None:
# tz-aware: preserve original timezone
return np.array(obj.to_pydatetime(), dtype=object)
return obj.to_numpy(dtype="datetime64[ns]")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the try-catch to be removed. Maybe it is better and more readable to do:
if..
elif
else
raise type error
Because by doing it like that you know exactly when a error is raised. now it could also be another problem being catched by the try-except construction

if all(hasattr(x, "tzinfo") for x in obj):
return np.array(obj, dtype=object)
else:
return np.array(obj, dtype="datetime64[ns]")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why return this specific dtype and not the dtype of the original obj?
this does not agree with your idea of backwards compatible i guess .

Does this work ?

Suggested change
return np.array(obj, dtype="datetime64[ns]")
return np.array(obj, dtype=obj.dtype)

if isinstance(obj, pd.DatetimeIndex) and obj.tz is not None:
# tz-aware: preserve original timezone
return np.array(obj.to_pydatetime(), dtype=object)
return obj.to_numpy(dtype="datetime64[ns]")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again: Why convert to this specific dtype?
Maybe it would be better to use the original dtype?

@RoosSchellevis RoosSchellevis force-pushed the fix/retain-timezones-in-input-profile branch from 109b846 to 7892a49 Compare December 10, 2025 09:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Timestamps in outputprofile do not match the inputprofile.

2 participants