BUG: timestamps are formatted without zero-padded years

[spencerkclark]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

>>> import pandas as pd
>>> pd.Timestamp(str(pd.Timestamp("0001-01-01")))
Timestamp('2001-01-01 00:00:00')
>>> pd.Timestamp("0001-01-01").isoformat()
'1-01-01T00:00:00'

Issue Description

With #49737 it is now possible to create Timestamp objects without four-digit years. The default and ISO formatted versions of them do not contain zero-padded years, which can lead to ambiguous date strings (#37071) and improper round tripping between str and Timestamp as illustrated in the example.

cc: @keewis

Expected Behavior

>>> import pandas as pd
>>> pd.Timestamp(str(pd.Timestamp("0001-01-01")))
Timestamp('0001-01-01 00:00:00')
>>> pd.Timestamp("0001-01-01").isoformat()
'0001-01-01T00:00:00'

Installed Versions

INSTALLED VERSIONS

commit : d3f0e9a
python : 3.8.5.final.0
python-bits : 64
OS : Darwin
OS-release : 22.2.0
Version : Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.5.0.dev0+2555.gd3f0e9a95d
numpy : 1.22.0.dev0+756.g5350aa097
pytz : 2020.1
dateutil : 2.8.2
setuptools : 49.2.0.post20200712
pip : 20.1.1
Cython : None
pytest : 5.4.3
hypothesis : 5.22.0
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.5.2
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : None
pandas_datareader: None
bs4 : 4.9.1
bottleneck : 1.4.0.dev0+78.g7c685ae
brotli :
fastparquet : None
fsspec : 0.7.4
gcsfs : None
matplotlib : 3.4.3
numba : 0.50.1
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : 1.8.0.dev0+1577.2f60c33
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : 0.20.3.dev517+g17933e76
xlrd : None
zstandard : None
tzdata : None
qtpy : None
pyqt5 : None

[keewis]

fixing this seems pretty easy: we'd only have to change

pandas/pandas/_libs/tslibs/timestamps.pyx

Line 1018 in 25c1942

base = f"{self.year}-" + base.split("-", 1)[1]

to

    base = f"{self.year:04d}-" + base.split("-", 1)[1] 

but that causes pandas/tests/scalar/timestamp/test_constructs.py::TestTimestampConstructors::test_out_of_bounds_string_consistency to fail, and I have no idea how to fix that.

Edit: actually, maybe it's the failing tests that need to change? It doesn't seem helpful to look at 1-01-01 00:00:00 without knowing which time it represents (001-01-01 and 0001-01-01 should be the same date, but 01-01-01 and 1-01-01 are interpreted as 2001-01-01).

[spencerkclark]

Thanks for looking into this @keewis! That's encouraging that it might be that easy.

I agree -- I think that test only fails because the error message changes in the way we would expect. I'm not sure I read any more into the original expected error message other than that it was consistent with how f"Cannot cast {self} to unit='{unit}' without overflow." appeared before for pd.Timestamp("0001-01-01").as_unit("ns").

[keewis]

the reason why I was confused was that immediately below that check there's this (I was confused mostly because of the comment):

pandas/pandas/tests/scalar/timestamp/test_constructors.py

Lines 605 to 610 in 6c50f70

	if arg == "0001-01-01":
	# only the 4-digit year goes through ISO path which gets second reso
	# instead of ns reso
	ts = Timestamp(arg)
	assert ts.unit == "s"
	assert ts.year == ts.month == ts.day == 1

where pd.Timestamp("001-01-01") == pd.Timestamp("0001-01-01"), so unless I'm missing something both should get a precision of "s", while "01-01-01" and "1-01-01" should have a precision of "ns".

In any case, I'll try to send in a PR tomorrow.

[spencerkclark]

Sounds good!

I see, yeah, I agree that comment is a little confusing and perhaps that part of the test could also be updated. For what it's worth (and maybe you've noticed this already) it looks like pd.Timestamp("001-01-01") in fact does get assigned second precision on the current main branch:

>>> import pandas as pd
>>> pd.Timestamp("001-01-01").unit
's'

It could be there was a brief time during recent development when it did not and the second option of the expected error messages occurred for "001-01-01" (raised by the Timestamp constructor rather than the as_unit call). Maybe it can be discussed in your PR. The good news is that I do not think it should block this formatting change one way or the other.