Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More consistent datetime conversion #136

Closed
2 of 3 tasks
shoyer opened this issue May 19, 2014 · 0 comments · Fixed by #294
Closed
2 of 3 tasks

More consistent datetime conversion #136

shoyer opened this issue May 19, 2014 · 0 comments · Fixed by #294

Comments

@shoyer
Copy link
Member

shoyer commented May 19, 2014

Todo:

  • Decide on rules for datetime conversion
  • Implement them
  • Document them

Currently:

  • All np.datetime64 arrays or objects are converted to ns precision
  • We leave other datetime or datetime-like objects intact in numpy arrays of dtype=object.

Arguably, we should convert everything to 'datetime64[ns]', if possible. This is the approach we now take for decoding NetCDF time variables (#126).

Reference discussion: #134. From @akleeman:

In #125 I went the route of forcing datetimes to be datetime64[ns]. This is probably part of a broader conversation, but doing so might save some future headaches. Of course ... it would also restrict us to nanosecond precision. Basically I feel like we should either force datetimes to be datetime64[ns] or make sure that operations on datetime objects preserve their type.

Probably worth getting this in and picking that conversation back up if needed. In which case could you add tests which make sure variables with datetime objects are still datetime objects after concatenation? If those start getting cast to datetime[ns] it'll start get confusing for users.

Also worth considering: how should datetime64[us] datetimes be handled? Currently they get cast to [ns] which, since datetimes do not, could get confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant