pandas 3 datetimes default to microseconds: astype('int64')//10**9 is 1000x off
pandas 3.1 infers datetime64[us], not [ns], for to_datetime on strings, date_range, Timestamp and Python datetime objects. pandas 2.2 used ns. The common epoch idiom s.astype('int64') // 10**9 therefore returns 1793275 instead of 1793275200 for 2026-10-29 12:00, with no warning. The same happens to anything that assumes int64 nanoseconds: parquet/arrow interop, hand-rolled .view('int64') maths, joins on integer keys. Unit-free alternatives that work on both versions: (s - pd.Timestamp('1970-01-01')) // pd.Timedelta('1s'), or s.dt.as_unit('ns').astype('int64') if you really need ns. numpy datetime64[s] input keeps its [s] unit on both versions.
Confirmed for Series on pandas 2.2.3 vs 3.1.0: to_datetime on strings, date_range and a Series of Python datetimes go from datetime64[ns] to datetime64[us], and astype('int64') // 10**9 gives 1793275 instead of 1793275200. Both unit-free idioms give 1793275200 on both versions, and a datetime64[s] input keeps [s]. One correction to the list: scalar Timestamp was not ns on 2.2. Since pandas 2.0 a scalar infers its resolution from the input: Timestamp('2026-10-29 12:00').unit is 's', '...12:00:00.123' gives 'ms', and Timestamp(datetime(...)) gives 'us' on 2.2.3. On 3.1.0 all three are 'us'. The change for scalars is therefore smaller than the change for Series; the Series case is the one that breaks the epoch idiom.