date_part returning wrong results due to overflows

[gabotechs]

Describe the bug

When playing with the date_part function, I see that there's ways of triggering int32 multiplication overflows that either panic on a debug build, or return the wrong number at runtime.

To Reproduce

Executing the following statement shows the behavior.

SELECT date_part('microsecond', timestamp '1970-01-01T00:40:00' - timestamp '1970-01-01T00:00:00')

DataFusion fiddle link <- returns a wrong random number

Postgres fiddle link <- returns 0

Expected behavior

The date_part function should behave the same as Postgres

Additional context

Not 100% sure, but I would say that the changes introduced in #13466 look suspicious. There, the inner calculations are using int32 types, which are easy to overflow. Special mention to this line of code:
https://github.com/gabotechs/datafusion/blob/763bd681f09d58ce285ab3a677b81291c41adfce/datafusion/functions/src/datetime/date_part.rs#L290-L290

[gabotechs]

It can also be replicated with intervals:

SELECT date_part('microseconds', interval '1 hour')
-- returns -694967296, but the result should be 0

[gabotechs]

It seems like even without integer overflows, the overall logic is wrong:

SELECT date_part('seconds', interval '1 hour')
-- returns 3600, but the result should be 0

[Omega359]

It seems like even without integer overflows, the overall logic is wrong:

SELECT date_part('seconds', interval '1 hour')
-- returns 3600, but the result should be 0

Hmm. I think this may be a separate issue as indeed it doesn't follow the typical pattern for that function where

SELECT date_part('seconds', interval '1 hour 5 second');

should return 5 (the seconds element in the interval, not the overall seconds the interval covers)