We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
It seems it returns different objects when passed array vs string:
In [1]: pd.to_datetime(['2012'])[0] Out[1]: Timestamp('2012-01-01 00:00:00', tz=None) In [2]: pd.to_datetime('2012') Out[2]: datetime.datetime(2012, 1, 1, 0, 0)
Also worth mentioning (though different):
In [3]: pd.Timestamp('2012') Out[3]: Timestamp('2012-06-13 00:00:00', tz=None)
Seems a little inconsistent... (cc #3859)
The text was updated successfully, but these errors were encountered:
to_datetime('') NaT
now....before return the empty_string...
better?
Sorry, something went wrong.
So it'll always do Timestamps? It's also weird it justs lets junk/integers through...
In [1]: pd.to_datetime('ssds') Out[1]: 'ssds' In [2]: pd.Timestamp(0) Out[2]: Timestamp('1970-01-01 00:00:00', tz=None) In [3]: pd.to_datetime(0) Out[3]: 0
with 0 now returns a Timestamp, so that I think is ok
the strings OTOH, you need to supply error='raise', default is ignore, change the default?
error='raise'
ignore
??
In [2]: pd.to_datetime('ssds') Out[2]: 'ssds' In [4]: pd.to_datetime('ssds',errors='raise') ValueError: unknown string format In [5]: pd.to_datetime(0,errors='raise') Out[5]: Timestamp('1970-01-01 00:00:00', tz=None) In [6]: pd.to_datetime(0) Out[6]: Timestamp('1970-01-01 00:00:00', tz=None)
Lol, I should have read the docstring there. Yeah, can't think why leaving it untouched would ever be what's wanted. ?
Thoughts on this one:
In [56]: pd.Timestamp('2012') Out[56]: Timestamp('2012-06-13 00:00:00', tz=None)
(picks todays date, but on the year of the string...)
Surely to_datetime(x) should be the same as map(Tinestamp, x) ?
Successfully merging a pull request may close this issue.
It seems it returns different objects when passed array vs string:
Also worth mentioning (though different):
Seems a little inconsistent... (cc #3859)
The text was updated successfully, but these errors were encountered: