← All functions

WEEKSINYEAR

Unsupported (not recognized)

Category: Date & Time · Last tested 2026-09-01

Real compatibility results for the WEEKSINYEAR function: executed in Excel for the web, Google Sheets and LibreOffice Calc, measured against LibreOffice’s published documentation. Excel does not document WEEKSINYEAR, so this page makes no claim about Excel. Syntax and links to that documentation are below.

Support matrix

EngineDocumentedLive-testedVerdict
Excel (desktop)No n/a (not an Excel function) n/a
Excel for the web— Yes (recalc, 2026-09-01) Unsupported (not recognized)
Google SheetsNo Yes (Drive import, 2026-09-01) Unsupported (not recognized)
LibreOffice CalcYes Yes (25.8.7.3, 2026-09-01) Supported, behaves as documented

LibreOffice version history

We executed the same test cases under each LibreOffice release to show exactly when WEEKSINYEAR’s support changed — not documentation claims, real results.

LibreOffice versionVerdictTested
24.2.0.3 Supported, behaves as documented 2026-09-01
24.8.7.2 Supported, behaves as documented 2026-09-01
25.2.0.3 Supported, behaves as documented 2026-09-01
25.8.7.3 Supported, behaves as documented 2026-09-01

Why isn’t WEEKSINYEAR working in Google Sheets?

Google Sheets does not implement WEEKSINYEAR: we imported the formula into Sheets on 2026-09-01 and every case came back #NAME? (unrecognized function). Sheets is a rolling service with no version to pin, so this is a statement about the service on that date, and Google’s own function list does not document it either. Rewrite the formula with a documented Sheets equivalent — see the Excel ↔ Sheets equivalents table.

Discovered quirks

Executed test cases

Excel for the web (executed 2026-09-01 via OneDrive recalculation)

These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.

FormulaDescriptionResultExpectedVerdict
=WEEKSINYEAR(DATE(1970,2,17)) LibreOffice's own published example: a 53-week year #NAME? 53
Provenance

LIBREOFFICE'S OWN PUBLISHED RESULT: "WEEKSINYEAR(A1) returns 53 if A1 contains 1970-02-17, a valid date for the year 1970." (The page prints the example without a leading '=', unlike its neighbours; the formula is otherwise as published, with DATE() substituted for the cell reference for the reason the sibling ISLEAPYEAR entry gives.) Derived independently as well: 1 January 1970 was a Thursday, and under the ISO rule the page states -- "Following ISO 8601, this function considers Monday to be the first day of the week, and the first week of a year is the one with most days in this year" -- a common year beginning on a Thursday has 53 ISO weeks. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch
=WEEKSINYEAR(DATE(2025,6,1)) A 52-week year, the ordinary case the page does not publish #NAME? 52
Provenance

DERIVED from the ISO rule the page states. 1 January 2025 was a Wednesday and 2025 is not a leap year, so it has 52 ISO weeks. The page publishes only a 53-week year, so this is the case that shows the function is computing rather than returning a constant. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch
=WEEKSINYEAR(DATE(2026,6,1)) A second 53-week year, on the other of the two ISO rules that produce one #NAME? 53
Provenance

DERIVED from the same ISO rule. A year has 53 ISO weeks when it begins on a Thursday, or when it is a leap year beginning on a Wednesday; 1 January 2026 is a Thursday. Computed independently here from the ISO week-date calendar rather than looked up. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch

Google Sheets (executed 2026-09-01 via Drive import)

Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.

FormulaDescriptionResultExpectedVerdict
=WEEKSINYEAR(DATE(1970,2,17)) LibreOffice's own published example: a 53-week year #NAME? 53
Provenance

LIBREOFFICE'S OWN PUBLISHED RESULT: "WEEKSINYEAR(A1) returns 53 if A1 contains 1970-02-17, a valid date for the year 1970." (The page prints the example without a leading '=', unlike its neighbours; the formula is otherwise as published, with DATE() substituted for the cell reference for the reason the sibling ISLEAPYEAR entry gives.) Derived independently as well: 1 January 1970 was a Thursday, and under the ISO rule the page states -- "Following ISO 8601, this function considers Monday to be the first day of the week, and the first week of a year is the one with most days in this year" -- a common year beginning on a Thursday has 53 ISO weeks. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch
=WEEKSINYEAR(DATE(2025,6,1)) A 52-week year, the ordinary case the page does not publish #NAME? 52
Provenance

DERIVED from the ISO rule the page states. 1 January 2025 was a Wednesday and 2025 is not a leap year, so it has 52 ISO weeks. The page publishes only a 53-week year, so this is the case that shows the function is computing rather than returning a constant. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch
=WEEKSINYEAR(DATE(2026,6,1)) A second 53-week year, on the other of the two ISO rules that produce one #NAME? 53
Provenance

DERIVED from the same ISO rule. A year has 53 ISO weeks when it begins on a Thursday, or when it is a leap year beginning on a Wednesday; 1 January 2026 is a Thursday. Computed independently here from the ISO week-date calendar rather than looked up. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Mismatch

LibreOffice Calc 25.8.7.3 (tested 2026-09-01)

FormulaDescriptionResultExpectedVerdict
=WEEKSINYEAR(DATE(1970,2,17)) LibreOffice's own published example: a 53-week year 53 53
Provenance

LIBREOFFICE'S OWN PUBLISHED RESULT: "WEEKSINYEAR(A1) returns 53 if A1 contains 1970-02-17, a valid date for the year 1970." (The page prints the example without a leading '=', unlike its neighbours; the formula is otherwise as published, with DATE() substituted for the cell reference for the reason the sibling ISLEAPYEAR entry gives.) Derived independently as well: 1 January 1970 was a Thursday, and under the ISO rule the page states -- "Following ISO 8601, this function considers Monday to be the first day of the week, and the first week of a year is the one with most days in this year" -- a common year beginning on a Thursday has 53 ISO weeks. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Matched
=WEEKSINYEAR(DATE(2025,6,1)) A 52-week year, the ordinary case the page does not publish 52 52
Provenance

DERIVED from the ISO rule the page states. 1 January 2025 was a Wednesday and 2025 is not a leap year, so it has 52 ISO weeks. The page publishes only a 53-week year, so this is the case that shows the function is computing rather than returning a constant. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Matched
=WEEKSINYEAR(DATE(2026,6,1)) A second 53-week year, on the other of the two ISO rules that produce one 53 53
Provenance

DERIVED from the same ISO rule. A year has 53 ISO weeks when it begins on a Thursday, or when it is a leap year beginning on a Wednesday; 1 January 2026 is a Thursday. Computed independently here from the ISO week-date calendar rather than looked up. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.

Matched

Docs & syntax

Where WEEKSINYEAR behaves differently