DOC add to_datetime to api.rst

[hayd]

Either I'm being thick or to_datetime isn't in the docs (does adding it like this add it?)

Should also put something in basics...?

[jreback]

there should be an example in timeseries.rst and/or basics.rst
but can't remember one

[cpcloud]

should be generated by the API docs. grin shows nothing in those that @jreback just mentioned

[hayd]

@jreback http://pandas.pydata.org/pandas-docs/dev/search.html?q=to_datetime&check_keywords=yes&area=default only result is "what's new".

Should one go in basics or timeseries? (I'd vote for basics.)

[jreback]

I would put near the top of timeseries (before time spans)
prob could create a separate section (conversions?)
as several options need to be explained, format, day first, tz,
and a link / mention in basics / dtypes

[hayd]

Can I include unit ? :)

[jreback]

yeh...goign to merge that right now in fact......

I think its a reasonable api, yes?

[jreback]

units defined in #3818

[jreback]

@hayd fyi...I believe that format option is currentlly ignored, remember that from somewhere...?

[hayd]

I was worried this was going to be a barrel of worms. maybe there is a reason this function isn't documented... :p

[jreback]

is it a barrel?

[hayd]

Nah... putting something together now. (sorry, just got flustered with above issue)

[hayd]

Also that dayfirst isn't strict. :S

[cpcloud]

@jreback @hayd merge?

[jreback]

I don't think this is ready yet

[cpcloud]

k

[hayd]

It could be merged as is, it would at least get to_datetime to the docs.

I've written "something" about using to_datetime in tseries api, but not pushed it yet...

[hayd]

I've done a little more on this, feedback welcome...

[hayd]

Probably could add something about raise here. (Also, I really dislike that this is default behaviour)

[cpcloud]

do u think that it should convert by default?

[hayd]

I think errors='raise' should be the default...

[jreback]

fyi...changing errors='raise' in theory a good idea, but breaks bunch of stuff.....will have to decide on that later...otherwise this looks ready?

[hayd]

just rebased, so will check I'm not saying anything stupid and then merge...

[cpcloud]

pd.to_datetime([1, '2']) is possibly surprising maybe note that?

[cpcloud]

dateutil defaults on making a date string of just an integer midnight on the current day iirc

[hayd]

@cpcloud woah! I'd never done: pd.to_datetime(['2']), er!! Will add it in.

[hayd]

That is also strange, and the thing which means that to_datetime isn't just map(Timestamp, x), I dislike examples where it isn't (but they need to be included).

[jreback]

this is good!

see #3890, which resolves almost all of the inconsistencies

[hayd]

Ah cool! Didn't realise hasn't been merged yet! :)

[jreback]

whilst -> while?

[hayd]

ok

[hayd]

This is still whacky:

[hayd]

In [4]: pd.to_datetime([1, '1'])
Out[4]:
<class 'pandas.tseries.index.DatetimeIndex'>
[1970-01-01 00:00:00.000000001, 2013-06-01 00:00:00]
Length: 2, Freq: None, Timezone: None

so will mention it

[cpcloud]

not sure there's any other way to go about it. need to use ints for representation but want to be able to parse semi human readable dates and ints...dateutil is extremely lenient except e.g., it won't parse an int. hopefully no one is abusing pandas in this way

[jreback]

can u add that last to #3944?

I think we are all agreed that the default to_ datetime should be more strict

[cpcloud]

done

[jreback]

that why I separated out #3944

dateutil lets everything thru

so have to do some most common case parsing first

need to expand c date parser then can pretty much drop need for dateutil except as fallback

[hayd]

(and it's not strict for dayfirst grrr!)

[hayd]

Quick once over of this?

[jreback]

looks good

[hayd]

a lot of likes and objects here, but I think it'll do

[jreback]

mergable?

[hayd]

I'm still meh on the first line, but I think it's fine.