ENH/COMPAT: update tests for dateutil 2.5.3

[jreback]

closes #12944

so this fixes the compat with all dateutils in the test suite
add the dayfirst and yearfirst args to Timestamp. This make testing and compat a lot
easier. xref discussion in #7599 where we didn't implement it, though the feeling was sort of +0.

[jreback]

cc @jorisvandenbossche @sinhrks

[jreback]

so we might want to ban 2.5.2 from being accepted in pandas because it has a bug in the dayfirst/yearfirst logic, though it will raise an error (rather than give incorrect results). Though its an edge case.

[sinhrks]

How about showing a warning?

[jreback]

@TomAugspurger @jorisvandenbossche comments? (or +1 ok too: :)

[jorisvandenbossche]

As I expressed (I think) my feeling about this in the previous discussions, I am (in principle) -1 on the addition of dayfirst/yearfirst to Timestamp (it is just not needed and bloats its constructor).
Is it really a big difference for the tests? I don't directly see how that would be a problem, I would just think that the yearfirst/dayfirst tests do not test for Timestamp?

[jorisvandenbossche]

Should the yearfirst be 0 here?

[jreback]

not sure what you mean, this is just printing out the 4 combinations of booleans (True/False).

[jreback]

@jorisvandenbossche IIRC you were not -1, but indifferent. But I dont' see why we are not compat, it just causes even more confusion. Yes this mainly fixes tests, but to be honest. Having Timestamp and to_datetime be pretty much exactly the same is a good thing.

[jreback]

ok I took dayfirst/yearfirst off of the public Timestamp constructor. So this is just a compat PR now that fixes up tests mainly.

[jorisvandenbossche]

@jreback sorry, late reply. I was maybe indeed more indifferent, anyway, you already merged now. It would maybe indeed be more easy (implementation wise) that to_datetime and Timestamp work similar, but my main concern is that I would not want us to encourage people to use Timestamp for anything else as manually constructing a timestamp when needed (and then you should always provide a standard string, and not use eg dayfirst), so not eg for parsing strings, as for this there is to_datetime.

[jreback]

@jorisvandenbossche yeah, I think would have to add format & dayfirst and weekfirst to be really consistent. I actually don't think its a big deal really. People mis-use pd.to_datetime all the time. So it gives them more fuel to the fire!

thanks for the comments.