Pandas 3.0.0 breaks timedelta precision

[hagenw]

pandas 3.0.0 changed the default precision when converting to timedelta: https://pandas.pydata.org/docs/dev/whatsnew/v3.0.0.html#datetime-timedelta-resolution-inference

This caused already an issue in a CI pipeline in auglib that used audformat.utils.to_segmented_index(), so we will need to adjust audformat to work with pandas 3.0.0 as well.

[hagenw]

The underlying change can be summarized as

In pandas 3.0.0, pd.to_timedelta() defaults to timedelta64[s] (seconds) precision instead of timedelta64[ns] (nanoseconds).

[hagenw]

We are affected by this in audformat.utils.to_segmented_index().

[hagenw]

We also need to check if other parts of the code might be affected.

[hagenw]

Here are some potential issues as discovered by Claude, but I think none of it needs to be fixed immediatly:

Potential Issues (Require Further Investigation)

1. union() function - utils.py:1985-1996 - HIGH PRIORITY

• Issue: Uses dtypes from the first index only
• Impact: Silent precision loss when combining indices with different timedelta precisions
• Example: Union of timedelta64[s] and timedelta64[ns] indices truncates sub-second values
• Recommendation: Modify to detect highest timedelta precision among all inputs and use that

2. intersect() function - Similar issue likely exists

3. concat() function in utils.py - May have similar issues

4. segmented_index() in index.py:357 - LOW PRIORITY

• Issue: The resulting dtype depends on input precision
• Impact: Integer inputs create timedelta64[s], float inputs create timedelta64[ns]
• Note: This is expected pandas behavior, not a bug per se

5. CSV loading in table.py:927 - LOW PRIORITY

• The pd.to_timedelta(x) converter for strings preserves precision from the string format

[hagenw]

One test for concat() was failing in the CI, so it seems also important to tackle union(), intersect(), and concat().