Wallet data3 min read

Date Ranges in Wallet Activity Reports

Choose inclusive and exclusive date boundaries for wallet history, convert them to chain ranges, and avoid duplicates between adjacent reporting periods.

Editorial illustration accompanying date ranges in wallet activity reports.

Overview

When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.

Two adjacent reports should not double-count their shared boundary. A useful convention is a half-open time interval: include the start instant and exclude the end instant. The API and the application must agree on that convention.

Specify instants rather than vague dates

A date such as 1 January needs a time zone before it becomes an instant. Store the requested zone, normalised timestamps and precision. Block timestamps are not the same as a user’s local transaction submission time. If the API uses inclusive block ranges, translate the time predicate deliberately instead of copying the same endpoint into both reports.

Worked example: adjacent months

January covers timestamps greater than or equal to 1 January 00:00 and less than 1 February 00:00 in the declared zone. February starts at that same February instant. An event exactly on the boundary belongs only to February. Retain the selected block range and the final timestamp filter used to obtain this result.

Test boundary records

Include events exactly at the start, exactly at the end and multiple events sharing one block timestamp. Test daylight-saving transitions when local calendar periods matter. Preserve transaction and event ordering within a block independently of time. A complete date-range report also needs a completed scan; correct timestamp comparisons cannot compensate for missing pages.

A practical acceptance test

Place events one instant before the period, exactly at its start, just before its end and exactly at its end. Adjacent half-open reports should include each eligible event once overall. Repeat the test using a local calendar period crossing a daylight-saving transition, checking the converted instants rather than assuming every day has the same duration.

Questions about the topic

Frequently asked questions

Should both ends be inclusive?

That can double-count a shared boundary between adjacent reports; declare the chosen rule.

Is block time the user’s submission time?

No. It describes the block context, not a precise individual submission event.

Standards & technical documentation

Further reading

{{TODO: author name}}

Practical explanations of blockchain data, software integration and the context behind a record.

About Indexbase
← Back to all articles

Build with better context.

Get an update when private beta opens.

Form setup in progress. Nothing entered here is sent or saved. {{TODO: endpoint}} See the full form and email alternative.