Hello
I can confirm the said defective behaviour with Numbers v2 as well. It is bug of duration parser which failed to parse sub milliseconds properly. It appears to parse 17:16:22.931355 as 17:16:22.355 + 0:0:931, that is it arbitrarily shifts 0.931355 [sec] by three decimal places to yield 931.355 [sec] and add this bogus value to integer part of seconds.
A workaround is not to let the miserable parser parse the duration value by, for instance, using raw days value 0.719709853645833 (= (17 * 3600 + 16 * 60 + 22.931355) / 86400) instead of 17:16:22.931355.
E.g.,

I myself always use real number reperentation of date and duration, i.e., days since 1904-01-01T00:00:00 and duration [sec] / 86400 respectively, in spreadsheet and never use date or duration object in Numbers except for display purpose.
Regards,
H