Weekly Reports in a Business App: Which Year Does Week One Belong To?
A weekly report needs more than a week number. Agree which calendar defines the week, store the corresponding week-year, and show the actual date span beside the label. If your app uses ISO weeks, the week-year can differ from the calendar year of a date near New Year. A filter labelled only “Week 1” leaves both the year and the reporting convention unresolved.
This matters when commissioning a sales dashboard, staffing report or customer portal that groups activity by week. It is a reporting-period identity decision, not a choice of calendar widget or a rule for booking appointments.
Name the convention before designing the filter
The WHATWG HTML definition of weeks describes seven-day periods beginning on Monday. Its first week is the one containing the first Thursday of the Gregorian year. It explicitly notes that the week-year of a day can differ from that day's Gregorian calendar year, and identifies this system as equivalent to modern ISO weeks.
Use that convention when it matches the business. Do not assume that every organisation's “working week” means the same thing. A shop may want a different trading period, while a manager may mean the previous seven completed days. Those are legitimate reporting requests, but should have their own names rather than being presented as ISO week numbers.
Write a scope sentence such as: “The weekly activity report uses ISO weeks, Monday through Sunday, and identifies each period by ISO week-year and week number.” This is a recommended project requirement, not a claim that a standard chooses your business policy.
Keep the week-year with the number
A database field containing only 1 is not an adequate identity for a recurring weekly report. Nor should an integration take a date's ordinary year and attach a separately calculated ISO week number without checking that they belong together.
The HTML standard defines a week string using a positive year, a hyphen, an uppercase W, and a two-digit week number. It also defines validity against the number of weeks in that particular week-year. Not every week-year has a week 53.
For an integration that adopts this format, agree the exact representation with the receiving system. Store and exchange the full period identity rather than expecting a translated heading to serve as a machine key. A customer-facing label can say “ISO week 1” in natural language while the underlying value preserves the week-year as well.
The source gives a useful boundary case: the week beginning Monday, 29 December 1969 is week 1 of week-year 1970. That is an illustration from the standard, not a statement that December records should always appear under the next year.
Show the dates that the report actually covers
Recommend displaying a start and end date alongside the week-year and week number. This gives staff a way to recognise the period without memorising week-number rules. Carry the same identity into the report title, downloaded file and any saved filter.
Also define which business date assigns a record to a week. An order's creation date, fulfilment date and payment date answer different questions. An ISO week label does not settle which of these is relevant. If the source is an exact timestamp, separately agree the reporting time zone before deriving the local business date. The existing guide to booking times and time zones explains why an unlabelled clock value is a different problem from period naming.
For a report that is still accumulating data, label the current week as incomplete. Do not make a partial period look directly comparable with a finished one merely because both have weekly labels. This is practical reporting guidance, not a rule imposed by the HTML week syntax.
Do not silently replace a missing period
If an imported value asks for week 53 in a week-year that has only 52 weeks, recommend rejecting it with a clear explanation. Quietly moving the records to week 1 changes the requested reporting period.
Similarly, distinguish “no records in this valid week” from “invalid week” and from “data could not be loaded.” A valid empty result is not evidence that the period identifier was wrong. When historical data uses another convention, document the conversion or keep the original convention explicit rather than relabelling it without reconciliation.
Ask for boundary-focused acceptance checks
Turn these decisions into testable acceptance criteria:
- A report retains both the week number and its week-year when saved, reopened and exported.
- A fixture spanning New Year assigns dates using the chosen convention, including a day whose week-year differs from its ordinary year.
- Valid week 53 and invalid week 53 cases are handled according to the actual selected week-year.
- The visible date span, selected filter and exported period refer to the same week.
- Changing the interface language changes readable labels, not the period identity.
- The team can distinguish an unfinished current period, a valid empty period and a failed request.
These are proposed checks for the commissioned implementation. They do not claim that a particular browser, report or customer system has already passed them.
What should go in the project brief?
Specify the week convention, complete period key, record date used for grouping, any reporting time zone, date-span label and handling of invalid imported periods. Keep a rolling seven-day view separately named if the business needs one.
That small agreement prevents a familiar argument at the year boundary: two teams can calculate different totals without either arithmetic calculation being wrong, because they have not asked for the same reporting period.