Looks like a bug here:

Should be using date.setUTC* functions here to avoid setting in the local timezone.

I'm also experiencing this date inaccuracy, with RAW files based on TIFF.

Here is what exifr returns

DateTimeOriginal: 2022-07-03T20:58:33.000Z, // inaccurate. This time is local, but Z indicates UTC. This should be 2022-07-04T02:58:33.000Z when using UTC.
CreateDate: 2022-07-03T20:58:33.000Z,       // inaccurate. This time is local, but Z indicates UTC. This should be 2022-07-04T02:58:33.000Z when using UTC.
OffsetTime: '-06:00', // accurate

For comparison, exiftool via CLI returns the following, which is all correct

Date Time Original: 2022:07:03 20:58:33-06:00
Create Date: 2022:07:03 20:58:33-06:00
Offset Time: -06:00

The fix may be to adjust the local time by the offset after creating the date object, by adding something like below after Line 57 in the tiff reviver and passing the offset into the reviveDate(string, offsetString). Example:

  const date = new Date(dateTimeOriginal);

  // Convert from string (e.g. -06:00) to number (e.g. -360)
  const offsetMin = Number(offsetString.split(':')[0]) * 60;
  // Change local time to UTC
  date.setMinutes(date.getMinutes() - offsetMin); 

In my experience, DateTimeOriginal is always in local time, so this works. But if you prefer the method to support UTC input as the comments indicate, then wrapping the setMinutes() in a conditional to not run when DateTimeOriginal is in UTC should do it:

  if (!isUTC)  { // pseudocode
      // Convert from string (e.g. -06:00) to number (e.g. -360)
      const offsetMin = Number(offsetString.split(':')[0]) * 60;
      // Change local time to UTC
      date.setMinutes(date.getMinutes() - offsetMin);
  }

@MikeKovarik I'd like to help solve this if you could guide how to get the datetime offset into the tiff river file please, because that seems to be the missing piece that would allow this code to be updated to convert the date object from local time to the correct UTC time.