Fix range boundary filtering for listTransactions.

[jonathanknowles]

Issue Number

#466

Overview

After adding some API tests to verify that listTransactions handles range boundaries correctly, I found that the function can sometimes return transactions that fall outside of the time range specified.

To fix this, I adjusted the recenter function to use the correct offset of slotLength − 1 picosecond, rather than slotLength − 1 second, since UTCTime values are of picosecond resolution.

The Enum instance for nominalDiffTime converts to and from an integer number of picoseconds, so we can use the pred function to subtract a single picosecond from slotLength.

Ranges tested by tests in this PR:

• Small ranges that marginally cover a transaction.
• Ranges with end times that are marginally earlier than a transaction.
• Ranges with start times that are marginally later than a transaction.

• Make the tests pass, by fixing the definition of listTransactions.

[piotr-iohk]

I am/was working on a similar range suite as part of #608 but with a precision of 1 second (as I thought this is the least we're operating at, since API is returning results with a precision up to the second as well).

In any case - lgtm! (when it comes to test scenarios)

[KtorZ]

👍

[jonathanknowles]

@piotr-iohk

In any case - lgtm! (when it comes to test scenarios)

Thanks for looking at this. Feel free to change anything that I've done to fit in better with your framework!

I am/was working on a similar range suite as part of #608 but with a precision of 1 second (as I thought this is the least we're operating at, since API is returning results with a precision up to the second as well).

I thought about this a bit over the weekend.

One issue with using seconds-based precision is that the UTCTime type itself has a precision to the nearest picosecond. The Iso8601Time type is just a wrapper around UTCTime. So when we produce a textual representation that allows for round trips, we have to be able to encode and decode values that have a given number of picoseconds.

Of course, we could change Iso8601Time so that we only allow values rounded to a second. However, this would have knock-on effects elsewhere in the codebase. (We'd have to change quite a few things, I think.)

I suspect it's just easier to allow any valid ISO 8601 date+time values, as we currently do.

Luckily, it's easy to increment or decrement values of UTCTime by mere picoseconds by using the succ and pred functions on values of NominalDiffTime:

% a = fromJust $ utcTimeFromText iso8601 "2000-01-01T00:00:00Z"
% a
2000-01-01 00:00:00 UTC
% addUTCTime (succ 0) a
2000-01-01 00:00:00.000000000001 UTC
% addUTCTime (pred 0) a
1999-12-31 23:59:59.999999999999 UTC