DAYS360 Function in Apple Numbers: Syntax and Worked Examples
Compare NASD and European 30/360 day counts in Numbers, handle duration results and build an explicit interest-model worksheet.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
Quick answer: =DAYS360(DATE(2008,2,27),DATE(2009,3,31),0) gives 394 days under Apple’s NASD example. Changing the last argument to 1 gives 393 days under its European example. This is a 30/360 convention, not the actual elapsed calendar-day count.
Availability and version history
- Introduced: Documented in Apple’s Formulas and Functions Help 15.4; the first introduction release and date remain unknown.
- Availability: Documented for Numbers in Apple’s Formulas and Functions Help 15.4; this documentation edition is not a final supported-version endpoint.
- Scope: Shared iWork reference; individual client introduction dates and older-release behavior are not established here.
- Checked: October 14, 2026, against the official DAYS360 reference. Documentation and independent calendar checks; no native Numbers test.
Syntax and method selection
=DAYS360(start-date, end-date, use-euro-method)
| Argument | Meaning |
|---|---|
start-date |
Starting date/time value or date string |
end-date |
Ending date/time value or date string |
use-euro-method |
Optional method: 0, FALSE or omitted selects NASD; 1 or TRUE selects European |
Apple says the time portions of the input dates are ignored. The method flag controls handling of dates on the 31st. The function uses twelve 30-day months per 360-day year; it does not count weekends, holidays or actual month lengths.
Apple’s examples show results such as 394d, a duration display. If subsequent arithmetic needs a plain number of modeled days, convert with DUR2DAYS, rather than treating a displayed duration as an untyped number. The conversion changes the representation, not the chosen day-count convention.
Reproduce the two documented methods
Create a blank table with at least twelve columns (A:L) and five rows. Put headers Start, End, NASD, European, NASD days, and European days in A1:F1. Enter these date formulas:
| Row | A: Start | B: End | Expected NASD | Expected European |
|---|---|---|---|---|
| 2 | =DATE(2008,2,27) |
=DATE(2009,3,31) |
394 days | 393 days |
| 3 | =DATE(2024,1,15) |
=DATE(2024,4,15) |
90 days | 90 days |
| 4 | =DATE(2024,1,1) |
=DATE(2025,1,1) |
360 days | 360 days |
| 5 | =DATE(2024,4,15) |
=DATE(2024,4,15) |
0 days | 0 days |
Enter =DAYS360(A2,B2,0) in C2 and =DAYS360(A2,B2,1) in D2. Fill both formulas down through row 5. In E2, enter =DUR2DAYS(C2); in F2, enter =DUR2DAYS(D2). Fill E2:F2 through row 5. These numeric columns should contain 394/393, 90/90, 360/360 and 0/0 respectively.
The first row reproduces Apple’s paired method examples. The other rows isolate ordinary 30-day-month arithmetic without a 31st-day adjustment. For example, January 15 to April 15 spans three modeled months, so its 30/360 result is 3*30=90.
The actual calendar interval from January 1, 2024 to January 1, 2025 is 366 days because 2024 is a leap year. DAYS360 still gives 360. That is expected for this convention, not a failure to recognize the leap year.
Check the default separately
Leave the table intact. In H2 enter =DATE(2008,12,20) and in I2 enter =DATE(2009,3,31). In J2 enter =DAYS360(H2,I2); this reproduces Apple’s omitted-method example of 101 days. Put =DAYS360(H2,I2,FALSE) in K2 and =DAYS360(H2,I2,0) in L2; both select the same documented NASD mode.
Use an explicit method flag in a shared financial model so a reader can see which convention was intended. Naming a calculation “30/360” without recording the method leaves an important assumption unstated.
Advanced example: a transparent simple-interest model
Use the numeric counts already in E2:F2. In H5, enter principal 10000; in I5, enter annual rate 6%. In J5 enter =H5*I5*E2/360 and in K5 enter =H5*I5*F2/360. Format J5:K5 as currency with two decimal places.
The expected modeled interest amounts are 656.67 under the 394-day NASD count and 655.00 under the 393-day European count. The unrounded difference is 10000*0.06/360, or approximately 1.6666667 currency units. The model uses simple interest with a 360-day denominator; it does not compound the rate.
This is a hypothetical arithmetic example. The applicable contract must specify the day-count convention, included periods, rates, fees and rounding. DAYS360 does not select those terms for you or establish the amount legally payable.
Actual days, working days and modeled days
Choose the function that matches the question. DATEDIF handles elapsed calendar intervals in its supported units, while NETWORKDAYS concerns working days. Neither is a drop-in substitute for a contract’s 30/360 convention.
Using DATE with numeric components avoids interpreting a text date differently under another regional setting. A date’s time-of-day component is ignored here, so this function is unsuitable for counting partial days or billing by the hour.
Boundary and portability cautions
- One-day method difference: compare the two explicit flags when an endpoint is the 31st; Apple’s first paired example demonstrates a real difference.
- February month-end: the short reference does not spell out every NASD adjustment or February-end variation. Do not assume that all external “30/360” algorithms implement identical rules.
- Reversed dates or malformed inputs: exact error and boundary behavior is not enumerated by the cited entry. The worked cases use ordered valid dates; confirm other cases in the intended version.
- Unexpected units in later arithmetic: use DUR2DAYS when you need a numeric count, and label it as modeled days rather than actual elapsed days.
- A result differs after export: compare known reference cases and the contract’s boundary dates, not only the formula name.
Keep the method flag alongside the input dates in any reusable template. It is part of the calculation’s meaning.