BUG: avoid specifying default coerce_timestamps in to_parquet

[jorisvandenbossche]

Looking into the usage question of #31572, I noticed that specifying the version to allow writing nanoseconds to parquet worked in plain pyarrow code, but not with pandas' to_parquet.
This is because we hardcode coerce_timestamps="ms" while the default is None, which has version-dependent behaviour (eg if version="2.0", actually write the nanosecond data)

[TomAugspurger]

Should this say "work without error"?

[jorisvandenbossche]

yes, of course ... !

[jreback]

thanks @jorisvandenbossche

[mnylen]

For us this change caused a nasty bug after upgrading from pandas 1.0.3 to 1.1.x. Apparently AWS Athena/Presto doesn't support nanosecond precision, so our timestamps started appearing with year 52000 when we created the parquet files using pandas 1.1.x. Just FYI for anyone else having the same issue. Adding coerce_timestamps="ms" (the previous default) to the to_parquet() call fixes the issue.

[findepi]

@mnylen FWIW, since recently Presto does support nanosecond precision for date/time types, including timestamps. (see trinodb/trino#1284 for more info).
However, this seems to be a different problem. If you can time, would you be able to answer a question in trinodb/trino#4662 (comment) so that we know what needs to be improved?

[mnylen]

@findepi I mentioned Presto only because AWS Athena uses that underneath. Athena is based on Presto 0.172, so it's likely that even if Presto nowadays supports nanoseconds for timestamps, it'll take a long time before Athena upgrades to the newer version.