TBILLPRICE Function (OpenOffice Calc)

• Introduced: First release not established; documented by OpenOffice.org 3.3.
• Supported in: Apache OpenOffice 4.1.16; this is a verified release, not a final supported version.
• Scope: Desktop Calc, English function names and semicolon-separated formulas.
• Checked: October 14, 2026. Eight ordinary reference formulas were recalculated from generated ODF in 4.1.16 on Linux x86-64, Build 9816. Source and independent arithmetic were checked.

TBILLPRICE returns a price per 100, but Apache OpenOffice 4.1.16 uses a specific implementation: it advances Maturity by one day, calculates the US 30/360 YEARFRAC to that adjusted date, and returns 100*(1-Discount*t). Do not assume an ordinary actual-days/360 Treasury-bill formula matches this release. Release implementation.

TBILLPRICE(Settlement;Maturity;Discount)

• Settlement, Maturity: date serials. Use valid increasing dates in an ordinary short-term example.
• Discount: positive annual discount rate as a decimal.
• Exactly three arguments; there is no selectable day-count basis or separate Redemption argument.

The native column contains saved 4.1.16 results; independent references use high-precision arithmetic and the stated source rules. Values are shown to twelve decimal places where needed. Enter DATE expressions directly rather than locale-dependent date text.

For January 1 to April 1, 2024 with Discount=0.05, the implementation uses January 1 to April 2 under US 30/360: t=91/360. The native price is approximately 98.736111111111. The calculation’s adjusted date and 30/360 rule are essential parts of this result.

For January 1 to January 31, 2024, advancing maturity to February 1 makes t=30/360 and the price approximately 99.583333333333. This example is useful because it exposes how month-end adjustment interacts with the extra maturity day.

The internal sequence is not generally equivalent to taking a US 30/360 difference at the original maturity and adding one. At January 1→January 31, that other sequence gives 31 days, while this function uses 30. TBILLYIELD follows the former sequence, so the two named functions do not share one universal period length.

For a separately specified actual-days/360 model using elapsed days excluding settlement, the same January 1→April 1 interval is also 91 actual days in leap-year 2024, so the values happen to coincide. That coincidence does not establish identical methods: January 1→July 1 has 182 actual days but this implementation uses 181/360. Independently checking dates that discriminate the rules is important.

The source checks Discount>0 and Settlement≤Maturity, advances maturity, and rejects a computed year fraction whose fractional part is zero. It does not express the same simple maximum-day guard as TBILLYIELD. No equal-date, long-term or invalid-domain cases were executed; all eight native examples are ordinary short-term dates.

Keep this implementation limitation prominent when translating formulas or reconciling a Treasury quote. Use the day-count convention actually required by the calculation rather than treating the function name as evidence of market-standard behavior. Prices here are per 100, with no fees or tax effects.

TBILLYIELD, PRICEDISC, DAYS360.

• Function-specific release implementation
• GetYearFrac date helper
• GetDiffParam date helper
• GetDiffDate360 date helper

The generated ODF produced the informational load warning “Not all attributes could be read.” The sheet was hard-recalculated and saved separately. All eight ordinary function identities, inputs and results were reconciled; a stale SUM cache changed from 999999 to 3 and an uncached SUM returned 7. This establishes the stated examples, not every workbook style or invalid input. Other explanatory identities are independent calculations. The authoring-tool XLSX was not executed in OpenOffice, and its preview values are not the native results reported here.