[DATA] Date-only XBRL durations are reported one day short in `reporting_periods`

[synfonia-llc]

Data Quality Issue Details

Issue Type:

• Incorrect financial values (wrong numbers)
• Missing financial data (expected data not present)
• Calculation errors (formulas producing wrong results)
• Data inconsistency (different values for same metric)
• Historical data problems (changes over time)

Environment

EdgarTools Version: 5.55.0 (editable distribution metadata is stale at 5.54.0)
EdgarTools Source: production edgar/** from main at a0ff18089c844ddfe81bd21a1c7c56f4ed629e55
Audit Worktree HEAD: 70c31469dc7e6d4b386a6f8fe4ce1276d48fca51
Python Version: 3.14.4
Operating System: Windows 11 (build 26200)

Financial Data Details

Company/Ticker: Apple Inc. (AAPL) and Netflix, Inc. (NFLX)
Form Type: AAPL 10-K; NFLX 10-Q
Filing Date/Period: AAPL year ended September 30, 2023; NFLX quarter ended March 31, 2024
Statement Type: XBRL reporting-period metadata

Specific Metric/Concept:

• Financial line item: Public XBRL.reporting_periods[*]["days"] duration metadata
• XBRL concept name: xbrli:startDate and xbrli:endDate context-period elements

Data Issue

Expected Value:

• Amount: AAPL 371 days; NFLX 91 days
• Source: Date-only context endpoints in the checked-in XBRL instances and XBRL 2.1 date semantics
• Page/section reference: AAPL context 2022-09-25 through 2023-09-30; NFLX context 2024-01-01 through 2024-03-31

Actual Value from EdgarTools:

• Amount: AAPL 370 days; NFLX 90 days
• How obtained: XBRL.from_files(instance_file=...).reporting_periods

Code to reproduce:

from pathlib import Path

from edgar.xbrl import XBRL

fixtures = [
    (
        "AAPL",
        Path("data/xbrl/datafiles/aapl/aapl-20230930_htm.xml"),
        "2022-09-25",
        "2023-09-30",
    ),
    (
        "NFLX",
        Path("data/xbrl/datafiles/nflx/2024/nflx-20240331_htm.xml"),
        "2024-01-01",
        "2024-03-31",
    ),
]

for ticker, instance_file, start, end in fixtures:
    xbrl = XBRL.from_files(instance_file=instance_file)
    period = next(
        p for p in xbrl.reporting_periods
        if p.get("start_date") == start and p.get("end_date") == end
    )
    print(ticker, {
        key: period.get(key)
        for key in ("start_date", "end_date", "days", "period_type")
    })

Cross-Verification

Have you verified this issue with:

• Multiple time periods for same company
• Multiple companies with same issue
• Direct SEC filing comparison
• Other financial data sources

Affects multiple periods/companies?

• Companies tested: AAPL and NFLX
• Time periods tested: a 53-week annual period and a calendar-quarter period
• Pattern observed: both date-only durations are exposed one day short; their period_type labels remain correct for these witnesses because classification uses ranges

Expected Behavior

What should happen:

reporting_periods[*]["days"] should respect XBRL 2.1 date-only endpoint semantics. The start denotes midnight at the beginning of startDate; the end denotes midnight at the end of endDate, so ordinary calendar-day duration includes the filed end day.

Data validation rules:

• AAPL September 25, 2022 through September 30, 2023 is 371 days.
• NFLX January 1 through March 31, 2024 is 91 days.
• A public duration derived from date-only XBRL endpoints must not silently omit the end day.

Additional Context

The date pairs are filed verbatim in the checked-in AAPL instance and NFLX instance. The corresponding SEC filing pages are AAPL accession 0000320193-23-000106 and NFLX accession 0001065280-24-000128.

XBRL 2.1 section 4.7.2 defines those date-only boundaries. InstanceParser._build_reporting_periods() parses both as Python date objects and computes (end_obj - start_obj).days, measuring only to the beginning of endDate.

A live search of the open and closed GitHub issue tracker is still required immediately before submission.

Impact Assessment:

• Minor (affects specific edge case)
• Moderate (affects common use cases)
• Major (affects core financial calculations)
• Critical (produces completely wrong results)

---

Data quality issues are high priority and will be verified against official SEC filings. Accuracy is fundamental to EdgarTools.