• Actually, I did forget to mention that my case was also taking care of the case where the fraction of the first date is larger than the fraction of the second date. So if you have a first date built using '1900-01-01 00:08:00.367', and a second date using '1900-01-01 00:09:18.361', you'll get a f.g of 00:01:18.0-6000000. This is because, even though the first date is actually earlier than the second, the fraction part is larger, and so you end up with a -6000000 as nsFraction. So in my case, I said if nsFraction is < 0, then add to nsFraction to 1000000000 to get the correct nanoseconds with correct fractional positioning.

    So there are two issues with your original query: the issue of losing position for the fractional part, and the issue where the fractional part, after doing the diff, turns out to be negative.

    Do you have another fix for the negative issue? I'd really like to see your take on this.