A report labeled for a day or an hour may leave its endpoint behavior unstated. Does the final boundary belong to that period, the following period, or both? If neighboring reports use incompatible assumptions, the same boundary record can appear twice or fail to appear where the business expects it.
Define interval membership before accepting a date-range filter. This gives business reviewers a practical question about records at the edge of a period, alongside separate checks of time-zone interpretation and timestamp meaning.
Describe the business period precisely
Consider a hypothetical operations dashboard that presents consecutive hourly periods. Its owner should specify what happens to a record whose relevant timestamp is exactly the shared boundary between two hours. A label such as from ten to eleven does not, by itself, decide that membership rule.
Also confirm which timestamp field the period uses. A range applied to request creation answers a different question from one applied to completion. The review should keep that choice explicit, but should not let it obscure the separate endpoint question. Even a correctly chosen field can be filtered with the wrong boundary convention.
Read the comparison’s inclusivity
PostgreSQL 18’s comparison documentation describes BETWEEN as including both range endpoints. That is a scoped predicate rule to understand when examining a query. It does not automatically establish that including both ends is the intended policy for a set of adjacent reporting periods.
For the hypothetical hourly dashboard, if two neighboring intervals both include their shared endpoint, an exactly matching record meets both interval definitions. This is a logical consequence of those stated boundaries, not an observed customer reporting defect. The implementation team should explain the actual filter rather than infer its meaning from the date labels displayed in the interface.
Test the boundary, not only the middle
The following proposed worksheet asks the report owner to approve membership for representative positions. It does not prescribe a universal time precision or query syntax.
| Record position | Question to resolve | Evidence to inspect |
|---|---|---|
| Exactly at the start | Is it included in this period? | Approved start rule |
| Inside the period | Does it use the intended field and scope? | Representative selected record |
| Exactly at the shared end | Which neighboring period owns it? | Explicit boundary policy |
| Just beyond the end | Is it excluded from this period? | Actual comparison behavior |
| Date-only interface input | What concrete boundary does the application send? | Prepared query parameters |
Do not substitute a convenient last instant for an unstated policy. The relevant team should identify the actual data precision and representation rather than assume every system shares one final representable fraction of a day.
Follow interface dates into concrete values
A user interface may ask for a start date and an end date while the query operates on timestamps. Ask what values the application actually sends and how those values implement the approved reporting period. The business owner need not inspect conversion code, but should see a representative example at the final boundary. Also ask whether an exported report and the on-screen report send the same concrete boundaries; matching date labels do not establish that two independently prepared requests use the same interval.
One possible policy is to include the period’s start and exclude the following period’s start. Another report may intentionally use inclusive endpoints for a different purpose. The review should assess the actual approved policy rather than insist that one form is always right. When definitions change, preserve the reason instead of describe a different population as a harmless formatting update.
Compare OceanBase using the same interval definition
OceanBase Database can be evaluated for transactional information and associated reports. Its Oracle and MySQL compatibility positioning does not establish that the application supplies the intended date parameters or that every field type and expression maps identically in the selected mode.
Retained MySQL, PostgreSQL, and an OceanBase implementation should use the same field, concrete boundary cases, and approved membership rule. Compare final included records before interpreting performance differences. A fast query that includes a different set of boundary records answers a different reporting question, even if the dashboard shows the same period label.
Accept neighboring periods together
A bounded proposed review should examine two adjacent periods and trace a record exactly at their shared boundary. It should also include ordinary inside and outside cases and the relevant interface path. No database queries, timestamp experiments, or customer report reconciliations have been executed here.
This question differs from converting time zones or deciding whether a database time function denotes transaction start. It concerns inclusion at an already defined interval boundary. Making that rule explicit helps buyers assess operational analytics without assuming that a familiar date-range label proves the intended records have been selected once and in the right period.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.