Part 117 vs Part 135 Flight Duty Time: Data Checklist

Executive Summary

Part 117 vs Part 135 flight duty time is primarily a question of United States (US) rule applicability and the data needed to explain a calculation. Part 117 of Title 14 of the Code of Federal Regulations (CFR) covers flightcrew members and certificate holders conducting Part 121 passenger operations, including specified related operations. Part 135 Subpart F separates several operation and crew categories; its unscheduled one- and two-pilot provision is not a universal Part 135 rule. Software selection should begin with those boundaries, then examine the operator's procedures and approvals. ^{[1] [2]}

The familiar headline limits conceal different measurement structures. Under Section 117.25(e), the baseline preceding-rest requirement is 10 consecutive hours, measured from duty release, providing 8 uninterrupted hours of sleep opportunity. Section 135.267(b), subject to paragraph (c), addresses 8 hours of flight for a one-pilot crew or 10 hours for a qualified two-pilot crew in 24 consecutive hours, including other commercial flying. These are different quantities, not competing settings for one generic duty clock. This report explains their data implications rather than calculating an operational clearance. ^{[3] [4]}

Packaged products already document useful capabilities. Cirro advertises offline duty entry and synchronization. Schedaero describes timestamped changes. FL3XX documents actual duty entry. Leon exposes an applied scheme and calculation limits. These are vendor statements, not independent demonstrations of accuracy or proof of coverage for a selected operator. The purchasing question is whether the configured product preserves the operator's necessary inputs, corrections and explanations through every connected system. ^{[5] [6] [7] [8]}

The proposed acceptance package consists of a field-level data contract, a scenario test matrix, and an audit handoff. It distinguishes planned from actual events, source time from ingestion time, original from corrected records, and missing data from a reviewed result. A database may normalize a timestamp to Coordinated Universal Time (UTC) while discarding its original zone, and message queues may deliver updates out of order; those behaviors make provenance and revision handling procurement requirements. A hypothetical schedule change and corrected actual show why a status must remain tied to its inputs and applicable rule. Regulatory questions remain with the operator's approved procedures and Federal Aviation Administration (FAA) principal inspector. ^{[9] [10] [11]}

Introduction and Background

Crew-scheduling managers, directors of operations and information technology (IT) teams often start a duty-tracking evaluation with the same question: can the product tell them whether a proposed assignment needs attention? That question becomes more useful when expanded: which operation, which crewmember, which source events, which rule version, and which unresolved exceptions produced the answer? Flight duty period (FDP) has a specific Part 117 definition; it should not be treated as a synonym for every duty interval stored in a roster. ^[12]

This report is explicitly about the United States, with research accessed on October 5, 2026. Current eCFR text was checked alongside the cited annual CFR editions. It examines Part 121 passenger flightcrew scheduling under Part 117 and relevant Part 135 crews under Subpart F. It does not transfer US thresholds to Canadian or European operations. The FAA's own flight-and-duty FAQ directs certificated operators to their principal inspector for further questions. No selected operator or approved alternative was supplied, so operator-specific applicability remains a review item. ^[11]

The central deliverable is a procurement and integration checklist, not a pilot calculator. A roster, dispatch record, crew application and reporting archive can each contain a plausible time without answering the same question. Schedaero, for example, distinguishes projected duty information from submitted flight logs, while FL3XX allows actual duty entry where scheduled and actual times differ. The contract should specify which event each source owns before any connector is implemented. ^{[13] [7]}

Custom integration can be relevant when a packaged tracker needs to receive or reconcile existing operational records. LANDING.AERO describes custom aviation applications and connecting existing systems and data sources. In this comparison it is an adjacent implementation option, not a packaged duty-rule engine or a regulatory contender. Its relevant role is making the operator's data contract executable around an existing workflow; product coverage and rule acceptance still need their own evidence. (Source: www.landing.aero) (Source: www.landing.aero)

Part 117: Passenger-Operation Data Requirements

Capabilities and Rule Structure

Part 117's applicability turns on the operation, not merely on an aircraft appearing in an airline roster. Section 117.1 also addresses specified Part 91 operations directed by a Part 121 certificate holder when a segment is a covered passenger operation. Preserve the assignment context and related legs rather than selecting a rule solely from the flight's commercial label. ^[14] Section 117.1(d) also permits Part 121 operations to follow Part 117 pursuant to the referenced Part 121 provisions; retain any applicable election in the configuration record. ^[15]

The data model must distinguish FDP end from duty release. The FDP definition ends when the aircraft is parked after the last flight, with no intention of further aircraft movement by that crewmember. The preceding-rest provision instead measures from release from duty. A single generic end-time field cannot explain both calculations unless its meaning is explicitly documented. ^{[16] [3]}

For unaugmented operations, Table B uses scheduled start in acclimated time and the number of flight segments. An integration therefore needs more than UTC elapsed time: it needs the selected start-time basis, segment classification and crew context. Preserve the inputs used in the calculation, even when a dashboard shows only one resulting duration. ^[17]

Adoption in an Operator's Workflow

Recommended configuration evidence includes:

• Operation mapping: The approved relationship between certificate holder, assignment and applicable rule.
• Crew context: Role, qualification context and acclimatization information supplied by an identified owner.
• Event definitions: Separate report, flight endpoint and duty-release records with named meanings.
• Historical coverage: Records needed for cumulative checks, with gaps visible before evaluation.

Reserve requires explicit categorization. Section 117.21 treats airport/standby reserve as part of FDP and provides distinct short-call reserve rules. A roster code such as AVAILABLE is insufficient without an agreed mapping to the relevant reserve category. The scheduling owner should approve that mapping and its effective dates. ^[18]

Strengths and Limitations

Structured rules provide clear questions for a vendor demonstration, but a rule label alone does not explain configuration. Request the rule package, effective version, underlying inputs and disposition of exceptions. Leon's documentation illustrates the type of visibility available in some systems by describing an applied scheme and limits shown in duty details. That feature is useful evidence to request, not proof that a particular US deployment is correctly configured. ^[8]

A Fatigue Risk Management System (FRMS) also cannot be represented by a generic override button. Section 117.7 requires FAA approval before exceeding provisions through an FRMS. Store any applicable approval reference and its scope as operator-controlled configuration, with an owner responsible for validating it. ^[19]

Part 135: Operation-Specific Duty and Rest Records

Capabilities and Rule Structure

Part 135 Subpart F separates scheduled passenger operations, other applicable operations, special helicopter emergency medical evacuation provisions and flight-attendant requirements. Section 135.261 also permits an eligible election to follow Section 135.265 with an appropriate operations-specification amendment. A tracker needs the actual Subpart F pathway and crew role, not simply a Part 135 checkbox. ^[2]

For unscheduled one- and two-pilot crews, Section 135.267(b) combines assigned flight time with other commercial flying. Paragraph (c) contains a conditional regularly assigned duty-period provision of no more than 14 hours. Treat that condition as a distinct rule context requiring evidence, rather than advertising an unconditional duty-day maximum. ^[20]

Paragraph (d) requires 10 consecutive hours of rest within the 24-hour period preceding planned assignment completion for paragraph (b) assignments. A changed completion estimate is therefore a meaningful input change. The system should retain the earlier plan, the revised plan and the resulting review record instead of rewriting the original forecast. ^[21]

Adoption in an Operator's Workflow

For Part 135 crew duty time tracking, proposed onboarding records include:

• Regime selection: Applicable Subpart F section and supporting operator approval or procedure reference.
• Crew assignment: Stable crew identity and the assignment's one- or two-pilot context.
• External activity: Other commercial flying supplied through an accountable declaration process.
• Rest evidence: Prospective rest designation, recorded boundaries and unresolved interruptions.

Some packaged products address external records. Schedaero documents ad-hoc flight-time logging, including flying outside the organization. That is a useful demonstration target: ask how the entry reaches calculations, how duplicate declarations are handled and whether historical corrections trigger renewed review. ^[22]

Strengths and Limitations

Cirro's published US rule list names 135.267 Non-Scheduled and 135.271 HEMS, the vendor’s helicopter emergency medical services designation. This supports a concrete coverage question but does not establish Part 117 coverage or every Subpart F pathway. Ask the supplier to identify the exact rules supported for the intended operator and demonstrate its configuration. ^[23]

Rest classification also depends on activity, not just elapsed time. Section 135.263 excludes specified required nonlocal transportation from rest. Preserve transport records and the operator's classification decision alongside the rest interval. A report that only displays free space between flights cannot supply this explanation by itself. ^[24]

The implementation recommendation is to make uncertainty visible. Unknown outside flying, unmapped duty codes or unconfirmed rest records should reach an assigned reviewer with a reason. The software result is evidence for that review, not a replacement for the operator's governing procedures.

Feature Comparison and the Data Contract

Compare Measurement Structures Before Products

Table 1 compares the information structures a buyer should evaluate. The cells identify documented distinctions and proposed review questions, not complete regulatory thresholds.

The meaningful comparison is thus a data-dependency comparison. Both contexts need trustworthy event records, but their classifications and measurement windows differ. Engineering components can be shared; rule selection and event meaning need explicit configuration. Vendor demonstrations should begin with the operator's assignments and event vocabulary rather than a prepopulated dashboard.

Field-Level Source Ownership

Table 2 is a proposed flight operations duty time data contract. Field names are illustrative. Sources of record and exception owners must be assigned locally; the table does not establish FAA-mandated database columns.

The contract prevents a connector from silently deciding what a field means. UTC, Coordinated Universal Time, is an interchange basis; it does not eliminate the need to retain local context. PostgreSQL explicitly notes that the original time zone is not retained in its timestamp-with-time-zone representation. Store that provenance separately when the operator needs to reconstruct a conversion. ^[9]

IANA explains that time zone data is updated when political rules change. ^[31] Releases have no fixed schedule. Record the release used by the conversion component, together with a policy for recalculating future plans after an update. This is an engineering recommendation, distinct from the rule engine's effective regulatory version. ^[35]

Packaged Product or Adapter Work

Public documentation shows that buyers can evaluate existing products before commissioning a separate interface. Flylogs describes configurable time limits and permitted crew edits; FL3XX documents operational application programming interface (API) endpoints and a changelog. Those features help define a demonstration, but they do not establish the precise coverage or contract terms of a deployment. ^{[36] [37]}

Use these procurement questions:

• Coverage: Which named US rules and operation categories are delivered and maintained?
• Configuration: Which operator procedures and approvals require separate implementation?
• Actuals: Which source wins when roster, crew and operations times disagree?
• Revision history: Are superseded payloads exportable, including author and reason?
• Access: Which endpoints and write permissions are contractually available?
• Updates: How are rule, API and schema releases announced and tested?
• Portability: Can the operator obtain inputs, explanations and review dispositions together?
• Demonstration: Can the supplier run the operator's correction and missing-data scenarios?

Access rights need separate verification. Flylogs ties API availability to account arrangements; FL3XX's getting-started documentation states that its API is included only in Premium. Schedaero advertises an open API, but that description alone does not establish every endpoint, historical export right or permitted write action. Obtain the relevant entitlement and scope in writing. ^{[38] [39] [40]}

Performance and Benchmarks: Scenario Acceptance Tests

Measure Evidence Quality, Not a Marketing Verdict

No independent accuracy, calculation-speed or labor-saving benchmark was established in this research. The proposed benchmark is an operator-owned test corpus with recorded inputs, expected review questions and replayable results. Label these tests acceptance evidence, not proof of regulatory compliance. Supplier claims and operational acceptance remain different evidence categories.

Table 3 proposes scenario-based tests for pilot duty time tracking software. Each test asks whether the workflow preserves necessary evidence and directs review; none delivers a legal pass/fail conclusion.

The table deliberately tests transitions, not just a clean first calculation. Microsoft recommends integration testing for projections, idempotency and schema evolution. ^[44] For a duty tracker, the corresponding evidence is whether a revised source event produces the expected reconstructed record while retaining the prior explanation. A repeatable result requires agreed event identity and revision precedence.

For example, Amazon SQS standard queues provide at-least-once delivery and may deliver messages out of order. Google Pub/Sub documents exactly-once support for pull subscriptions, with a stable message ID across redelivery. Neither description justifies assuming that business events are unique or correctly sequenced in an unspecified integration. Verify the actual connector configuration. ^{[45] [46] [47]}

Hypothetical Example: A Schedule Change and Corrected Actual

The following times are invented test inputs, not a real flight or an operational recommendation. A US assignment initially records report at 12:00Z, planned completion at 20:00Z, and planned duty release at 20:30Z. A later schedule revision records planned completion at 21:00Z. After the assignment, a crew submission records actual duty release at 21:20Z, later corrected to 21:50Z.

The test asks the system to retain each state rather than judge the assignment here. In Part 117, the reviewer needs separate FDP and duty-release endpoints; under the relevant Part 135 pathway, planned completion also matters. Missing crew context, prior records or rule selection prevents a defensible legal answer. ^{[12] [21]}

Expected review evidence is:

• Original plan: Its source assignment and revision identifiers.
• Revised plan: The changed completion event and schedule author.
• First actual: Its source timestamp, ingestion timestamp and submitting actor.
• Correction: The superseded record, reason and authorized revision.
• Result history: Each calculation's input set and configuration reference.
• Open questions: Missing fields and alerts requiring human disposition.

Schedaero says the latest saved flight log supersedes the previous version. A buyer should therefore ask how earlier payloads remain available for explanation or export; supersession and timestamping do not themselves establish immutable historical retention. FL3XX's documented synchronization indicator offers another useful test: whether visible freshness corresponds to the specific records used in a result. ^{[48] [49]}

Data Analysis and Evidence

Quantified Rule Inputs Are Not Product Benchmarks

The useful quantitative evidence here concerns measurement windows and table parameters, not market size or software demand. The January 2025 official CFR edition lists unaugmented Table A flight-time limits of 8 hours for the 0000 through 0459 reporting band, 9 hours for 0500 through 1959, and 8 hours for 2000 through 2359. These examples describe that table's stated context; they are not universal duty limits. ^[50]

The same annual edition's Table B illustrates why a segment count matters. Within the 0700 through 1159 acclimated-start band, it lists 14 hours for one or two segments and 11.5 hours for seven or more. The current eCFR Table B confirms the scheduled-start and segment-count structure. The annual PDF is dated evidence, so implementation should retain the current rule package and reconcile its values against the current text. ^{[50] [17]}

Historical windows create another data requirement. Section 117.23 includes flight-time limits of 100 hours in 672 consecutive hours and 1,000 hours in 365 consecutive calendar days, and FDP limits of 60 hours in 168 consecutive hours and 190 hours in 672 consecutive hours. These examples explain why a same-day roster is insufficient input for all evaluations. The source also specifies the scope of flying included, which must be reflected in the operator's intake process. ^[51]

Section 135.267 instead includes commercial-flying limits of 500 hours per calendar quarter, 800 hours in two consecutive calendar quarters, and 1,400 hours per calendar year. Calendar-based and consecutive-hour windows should remain explicitly typed in the rule configuration and audit explanation. Avoid converting every historical requirement into one generic rolling counter. ^[52]

A Measurable Acceptance Evidence Set

Suggested measurements, with targets selected by the operator, include:

• Completeness: Required source fields present versus missing for each assignment.
• Freshness: Difference between source event time and received time, grouped by source.
• Correction coverage: Revisions linked to the prior record and a responsible actor.
• Replay agreement: Historical results reproduced using the recorded inputs and configuration.
• Exception closure: Alerts with a reviewer, disposition and supporting evidence.
• Export coverage: Required source and transformed records included in the handoff package. ^[34]

These are proposed engineering measures, not FAA thresholds or observed vendor scores. NIST's log-management guidance supports preserving original logs and checking transferred-log integrity. Its publication is from 2006; this report uses those general principles without recommending its historical cryptographic examples. ^[34]

Fatigue assessment also extends beyond a duty-counter result. FAA AC 120-103A identifies time since sleep, time of day, multiple time zones and workload among fatigue factors. A documented limit evaluation should remain distinct from the operator's broader fatigue-management process. No numerical software score in this report measures fatigue risk. ^[53]

Implications and Future Directions

The practical decision is whether the chosen tracker can demonstrate the contract using the operator's data. If it can, purchase and configuration may cover the requirement. If a necessary source, revision workflow or export is missing, an adapter may be justified. The gap should be stated as an observable requirement, such as preserving original timestamps or exporting superseded records, rather than a general claim that the market lacks suitable tools.

Existing documentation supplies specific starting points. Leon exposes an Air Operator Certificate (AOC) revision reference and acclimatization information in its duty API object. SMS Pro documents management notifications and reports for accounting export. These features suggest targeted demonstrations; an accounting report should not be assumed to contain a complete regulatory audit package. ^{[54] [55] [56]}

The integration contract also needs authorized access and version management. FL3XX asks integration applicants to identify data read/write needs, and its API documentation describes a changelog. RosterBuster's developer documentation requires user permission for roster exchange. A source being technically readable does not establish the operator's contractual entitlement to every record or action. ^{[57] [58] [59]}

Custom work should preserve the operator's ownership of event definitions, rule applicability and review. LANDING.AERO's first-party description emphasizes tailored flight-operations software, including integration, automation and dashboards. That model can be relevant to the adapter scope identified here; it does not establish a supplied Part 117 or Part 135 compliance product. (Source: www.landing.aero)

The proposed handoff checklist is:

• Coverage record: Applicable operation categories, crew roles and selected rule packages.
• Source map: Named owners and precedence for every required event.
• Access record: Confirmed endpoints, permissions and export entitlements.
• Time policy: UTC conversion, original zone retention and deployed time-data release.
• Revision policy: Stable IDs, correction lineage and handling of late updates.
• Test corpus: Representative scenarios and expected human review questions.
• Alert workflow: Named exception owners and required disposition evidence.
• Audit export: Inputs, changes, explanations and operator configuration references.
• Release process: Schema and rule changes reviewed before use.
• Acceptance record: Operator signoff on the demonstrated workflow and remaining limitations.

This handoff turns a product evaluation into a reviewable operational-data specification. Future changes can then be assessed against known inputs and tests rather than a remembered dashboard demonstration.

Conclusion

The answer to Part 117 vs Part 135 flight duty time is not a universal difference between two duty-day numbers. The comparison starts with the applicable US operation and crew context, then follows the event meanings, classifications and historical windows used by that context. A trustworthy tracker must make those dependencies explainable to the people responsible for reviewing them.

The proposed procurement approach has a concrete sequence. Establish the operator's rule-path inventory. Assign sources of record and event owners. Separate plans, actuals and corrections. Demonstrate reserve, transport and outside-flying intake where relevant. Test missing, duplicate, late and revised records. Finally, require an audit handoff that preserves inputs, configuration, result explanations and human dispositions.

Packaged software and custom integration should be assessed against that same contract. A packaged feature may already solve the requirement; an adapter may be needed where an operational source or workflow is absent. Neither choice changes the underlying regulatory obligation. Public product documentation is a starting point for questions, while operator-specific demonstrations and approved procedures determine whether the intended implementation is usable.

The resulting decision is narrower and more defensible than buying a generic green status indicator. It identifies what the system knows, where that knowledge came from, which rule and configuration were applied, what changed, and what still requires review. That is the appropriate foundation for evaluating flight duty time tracking software in a US flight operation.