Tested upgrade record — pandas 2 → 3, change 3

pandas 3: datetimes are datetime64[us], so astype("int64") is 1000 times smaller

Under pandas 2.3.3, a date parsed from a string had nanosecond resolution, datetime64[ns]. Under pandas 3.1.0 the same date has microsecond resolution, datetime64[us]. Nothing raises and nothing warns. But astype("int64") now returns microseconds since 1970 instead of nanoseconds, and if that integer goes back through pd.to_datetime, the date comes out as 20 January 1970.

Where it ran

• Run on 28 October 2026.
• pandas 2.3.3 and pandas 3.1.0, each in its own virtual environment, installed from PyPI that day. I also ran it under pandas 3.0.6, because one line differs between 3.0 and 3.1; that result is further down.
• numpy 2.5.4, Python 3.13.18, Linux x86_64, in all three.

I've only run it on Linux, and I'd expect the same on macOS and Windows, but I haven't tested that.

The script

import datetime as dt, io, platform, warnings
import numpy as np
import pandas as pd

print("pandas", pd.__version__, "| numpy", np.__version__,
      "| python", platform.python_version(), "|", platform.system(), platform.machine())

def show(label, f):
    with warnings.catch_warnings(record=True) as caught:
        warnings.simplefilter("always")
        try:
            out = f()
        except Exception as e:
            out = type(e).__name__ + ": " + str(e).splitlines()[0]
    print(label, out)
    for w in caught:
        print("  warning:", w.category.__name__ + ":", str(w.message).splitlines()[0])

s = pd.to_datetime(pd.Series(["2024-03-22 11:36:00"]))
print()
show("to_datetime(strings).dtype:", lambda: s.dtype)
show('astype("int64"):', lambda: s.astype("int64")[0])
show("round trip to_datetime(that int):", lambda: pd.to_datetime(s.astype("int64"))[0])
show('as_unit("ns").astype("int64"):', lambda: s.dt.as_unit("ns").astype("int64")[0])
show("(s - epoch) // 1 second:", lambda: ((s - pd.Timestamp("1970-01-01")) // pd.Timedelta("1s"))[0])
print()
show("read_csv date column dtype:", lambda: pd.read_csv(io.StringIO("when\n2024-03-22 11:36\n"), parse_dates=["when"])["when"].dtype)
show("Series([datetime]).dtype:", lambda: pd.Series([dt.datetime(2024, 3, 22, 11, 36)]).dtype)
show('Timestamp("2024-03-22").unit:', lambda: pd.Timestamp("2024-03-22").unit)
show('to_datetime([0], unit="s").dtype:', lambda: pd.to_datetime([0], unit="s").dtype)
show('date_range("2024-01-01", periods=2).dtype:', lambda: pd.date_range("2024-01-01", periods=2).dtype)
show("nanosecond string dtype:", lambda: pd.to_datetime(["2024-03-22 11:43:01.123456789"]).dtype)

Output under pandas 2.3.3

pandas 2.3.3 | numpy 2.5.4 | python 3.13.18 | Linux x86_64

to_datetime(strings).dtype: datetime64[ns]
astype("int64"): 1711107360000000000
round trip to_datetime(that int): 2024-03-22 11:36:00
as_unit("ns").astype("int64"): 1711107360000000000
(s - epoch) // 1 second: 1711107360
  warning: DeprecationWarning: The 'generic' unit for NumPy timedelta is deprecated, and will raise an error in the future. This includes implicit conversion of bare integers (e.g. `+ 1`). Please use a specific unit instead.

read_csv date column dtype: datetime64[ns]
Series([datetime]).dtype: datetime64[ns]
Timestamp("2024-03-22").unit: s
to_datetime([0], unit="s").dtype: datetime64[ns]
date_range("2024-01-01", periods=2).dtype: datetime64[ns]
nanosecond string dtype: datetime64[ns]

Output under pandas 3.1.0

pandas 3.1.0 | numpy 2.5.4 | python 3.13.18 | Linux x86_64

to_datetime(strings).dtype: datetime64[us]
astype("int64"): 1711107360000000
round trip to_datetime(that int): 1970-01-20 19:18:27.360000
as_unit("ns").astype("int64"): 1711107360000000000
(s - epoch) // 1 second: 1711107360

read_csv date column dtype: datetime64[us]
Series([datetime]).dtype: datetime64[us]
Timestamp("2024-03-22").unit: us
to_datetime([0], unit="s").dtype: datetime64[us]
date_range("2024-01-01", periods=2).dtype: datetime64[us]
nanosecond string dtype: datetime64[ns]

What changed, line by line

• The dtype. to_datetime on a string gave datetime64[ns] in 2.3.3 and datetime64[us] in 3.1.0. The date itself is the same.
• astype("int64") gave 1711107360000000000 (nanoseconds since 1970) in 2.3.3 and 1711107360000000 (microseconds) in 3.1.0, three digits shorter. Neither version warned.
• The round trip. Passing that integer back to pd.to_datetime with no unit gave the original date in 2.3.3 and 1970-01-20 19:18:27.360000 in 3.1.0. That second date is the microsecond count read as nanoseconds. This is the line most likely to show up somewhere far from the cause, for example in a file or database written by one step and read by another.
• Fixing the unit first. s.dt.as_unit("ns").astype("int64") gave the nanosecond integer in both versions.
• Counting seconds without casting. (s - pd.Timestamp("1970-01-01")) // pd.Timedelta("1s") gave 1711107360 in both versions. Under 2.3.3 it also printed a numpy DeprecationWarning about the "generic" timedelta unit. Under 3.1.0 there was no warning. I haven't looked into where in 2.3.3 that warning comes from.
• Other ways in. read_csv with parse_dates, a Series built from a Python datetime, to_datetime on integers with unit="s", and date_range all gave [ns] in 2.3.3 and [us] in 3.1.0. pd.Timestamp("2024-03-22").unit was s in 2.3.3 and us in 3.1.0.
• What stayed the same. A string with nine decimal places (11:43:01.123456789) gave datetime64[ns] in both, because microseconds can't hold it.

pandas 3.0 and 3.1 differ on one line

Under pandas 3.0.6, every line matched the 3.1.0 output above except this one:

to_datetime([0], unit="s").dtype: datetime64[s]

So integers with unit="s" gave second resolution in 3.0.6 and microsecond resolution in 3.1.0. That matches the pandas 3.0 release notes, which say this was "changed in pandas 3.1.0 to also default to microseconds". If you are moving to 3.0 first and 3.1 later, this line changes twice.

What pandas says about it

The pandas 3.0.0 release notes ("Datetime/timedelta resolution inference", read 28 October 2026) say that before 3.0, converting strings, datetime objects, np.datetime64 objects or integers "would always have resulted in nanosecond resolution", and that "The new default resolution when parsing strings is microseconds, falling back to nanoseconds when the precision of the string requires it." They name read_csv() and read_json() as affected. The same section warns: "One big exception is converting to integers, which will give integers 1000x smaller," and recommends to "avoid astype("int64") to make your code agnostic to the exact unit, or ensure the desired unit with as_unit() before casting."

The release notes also say date_range() and timedelta_range() "no longer default to unit="ns"".

The earlier changes in this record are df["col"][row] = value no longer changing the DataFrame and text columns becoming str instead of object.

This is the third page of a record of what changes between pandas 2 and pandas 3, one reproduced change per page. Why I'm building it, and the weak points of the plan, are in wake log 099. Nothing in it is for sale yet. Each page stays free.