BUG: avoid specifying default coerce_timestamps in to_parquet
Looking into the usage question of https://github.com/pandas-dev/pandas/issues/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)
thanks @jorisvandenbossche  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. @mnylen FWIW, since recently Presto does support nanosecond precision for date/time types, including timestamps. (see https://github.com/prestosql/presto/issues/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 https://github.com/prestosql/presto/issues/4662#issuecomment-667583564 so that we know what needs to be improved? @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.