YEARFRAC in ONLYOFFICE Spreadsheet Editor

• Introduced: Original introduction release is not established by the sources checked.
• Available: Documented in current unversioned ONLYOFFICE function help, checked October 18, 2026.
• Implementation inspected: Official SDKJS v10.0.0.169, commit 3679e0375a758d7dc59d31337a45461be3525ed8. This establishes a source snapshot, not identical behavior in every installed editor.
• Retired or deprecated: Retirement or formal deprecation is not established by these sources. A legacy spelling is not automatically a removed function.
• Testing: Examples are independently calculated or labeled source predictions. No ONLYOFFICE application or calculation-engine execution was performed. No native screenshot or general import/export guarantee is claimed.

Use English names and comma separators as shown; adapt separators outside quoted text if your locale requires semicolons. Keep full precision in calculations and round only the displayed summary.

=YEARFRAC(start_date, end_date, [basis])

Two or three arguments are registered. Dates should be numeric date values, preferably constructed with DATE. The result is a fraction measured in years, not an integer day count or a rounded count of anniversaries.

The basis-1 implementation detail matters: “actual/actual” is not one universal denominator shared by every product or financial instrument. This guide describes the inspected source, not every convention carrying that label.

1. Put =DATE(2025,1,1) in A2 and =DATE(2025,7,1) in B2.
2. Put basis codes 0, 1, 2, 3 and 4 in D2:D6.
3. In E2 enter =YEARFRAC($A$2,$B$2,D2) and copy down.
4. Independently expected results are 0.5, 181/365, 181/360, 181/365 and 0.5, respectively.

The actual interval contains 181 days. A 30/360 construction counts six synthetic months, or 180 days, then divides by 360. Actual/360 retains the 181-day numerator and gives 0.502777777778. Actual/365 gives 0.495890410959. These values differ because the definitions differ, not because the sheet has rounded the same calculation inconsistently.

If a stated annual amount is 1200 and a model explicitly uses a year fraction, multiplying by 0.5 yields 600, whereas multiplying by 181/365 yields approximately 595.068493151. This arithmetic does not decide which convention the model ought to use.

Consider December 31, 2024 to January 1, 2025. The actual interval is one day. For basis 1, the inspected helper averages the lengths of every calendar year from the earlier endpoint year through the later endpoint year, inclusive. The average is (366+365)/2=365.5.

Thus the source-derived expectation is 1/365.5 ≈ 0.00273597811218, rather than necessarily 1/366 or 1/365. This rule applies even though the interval is only one day. For a same-year interval, the denominator is simply that calendar year’s 365 or 366 days.

For a longer span, the helper likewise averages all included calendar years and divides the actual day difference by that average. It is not a split calculation that separately divides each part by its own year length. Do not infer parity with a different product’s actual/actual method from the shared basis label.

The helper truncates date objects before computing the fraction, so time-of-day components are excluded. For example, adding an afternoon fraction to a DATE value does not turn a whole-day YEARFRAC model into an hourly accrual model.

The inspected helper uses absolute differences. Reversing January 1 and July 1, 2025 with basis 3 still gives 181/365, not a negative value. If a workflow requires signed elapsed time, keep the chronological sign separate rather than assuming YEARFRAC will preserve it. Equal dates give a zero numerator under the ordinary valid-basis paths.

Documentation/source disagreement: help says decimal basis inputs are truncated. In the inspected wrapper, however, basis is passed directly to the helper’s switch without integer truncation. A value such as 1.9 matches none of the cases and produces the numeric-error category, conventionally #NUM!. Use exactly 0, 1, 2, 3 or 4. This is a source prediction, not a native observed error.

For February 28 to March 31, 2025, basis 0’s dedicated helper adjusts the February start to day 30 but leaves the March end at 31 in that branch, giving 31/360 ≈ 0.0861111111111. The separate DAYS360 FALSE helper traces to 30 for the same dates. Therefore YEARFRAC(a,b,0)=DAYS360(a,b,FALSE)/360 is not a safe general identity for this inspected release.

Basis 4 adjusts 31st-day boundaries using the European method, while basis 2 and 3 use actual days. Keep a small set of month-end and leap-year control examples alongside a financial or scheduling model. Validate the implemented convention against the specification that matters for your use case.

Negative input serials explicitly return the numeric-error category; conversion errors propagate. Unsupported basis values also produce that category through the helper’s default branch. These guards do not establish all valid maximum-date behavior, text-date parsing, blank handling or array semantics.

A date-looking cell format does not guarantee that its underlying value represents the intended date system. Construct modern control dates with DATE and inspect results before importing serials from another workbook. No general cross-product equivalence, native calculation result or workbook round-trip result is claimed here.

These are independent mathematical expectations or identified source-error predictions, not native application results. Preserve full input precision when reproducing them.

Use the exact input representation, date system and day-count convention above when moving a workbook between products. Similar names are not a general cross-version or file-format compatibility guarantee.

DATE constructs the endpoints; YEAR helps inspect which calendar years affect basis 1; ROUND controls reporting precision after the unrounded fraction has been checked.

• Official YEARFRAC help, checked October 18, 2026.
• Pinned SDKJS implementation, including parameter validation and numerical helpers.