Looks like a syslog event that had a secondary timestamp slapped on somewhere along the line... and by default Splunk will grab the first proper timestamp it finds.
The best thing to do in the long run is to reconfigure the timestamp detection for that sourcetype to have Splunk use the correct one. That's an index-time change though, so it won't work retroactively.
To get a quick win you can extract that timestamp into a field, apply the transaction, and do the maths yourself. Something along these lines:
base search | rex "(?<mytime>\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d.\d{6}(?:\+|-)\d\d:\d\d)" | eval mytimeepoch = strptime(mytime, "%Y-%m-%dT%H:%M:%S.%6N%Z") | transaction event_id | eval myduration = tonumber(mvindex(mytimeepoch, -1)) - tonumber(mvindex(mytimeepoch, 0))
Untested and with ugly field names, but it should work. Basically it extracts its own timestamp, lets the transaction create a multivalued field for that, and subtracts the first value from the last. Make sure that actually grabs the minimum and maximum value though.
