>>>>Hi,
>>>>
>>>>In my application Week Number is a very important concept. And from the beginning of the app (many years ago), in my code, I always considered week by Monday of the week. That is, a week should have Monday.
>>>>Next year, 2019, is a little challenging. The 1st of January falls on Tuesday. So, my app will consider the first week to be Week of January 7th (first Monday). But I know that many customers will not accept it (or at least will not understand it). And they will still think of the week of December 31 of 2018 as the first week of 2019.
>>>>I can change it in code (I think) and have the program re-calculate the 1st week and then always, when looking for a week #, to take into account that the first week was actually not the full week.
>>>>
>>>>Do you think that I should just stick to my initial design and have the week of January 7th, 2019 to be the first week of the year? Or re-calculate (kind of late but I can do it).
>>>>
>>>>TIA
>>>
>>>Let me come at this from a different angle - you mentioned you're talking about changing the code. So I'm assuming you have code in the application that is driving the date aggregations.
>>>
>>>I always create a date dimension table (a calendar table) with 1 row per date and columns for what that date represents.
>>>
>>>So the table might have a date column, date description, day of week, day of month, fiscal week, month to which it belongs, quarter, etc. And since I've had applications that had to support multiple date hierarchies (like a fiscal definition and a regular calendar definition), it might mean sets of columns.
>>>
>>>I know that doesn't answer your initial question, but just wanted to make that suggestion. Abstracting all of that into a table with the necessary columns usually makes reporting easier.
>>
>>I have read quite a bit about date table approach. I don't use it; good or bad, this is the way I designed it many years ago. So, for now, I decided to leave things as is. I actually remember a few years ago, there was the same case where the 31st fell on Monday.
>>I will just send all customers email explaining how things work in my app. Hopefully they will read :)
>>Thank you for your input.
>
>There is also the possibility that someone may throw a spanner into the works by declaring that as of a particular date, the way week of year would change -- either by changing the starting day of week or if we're considering partial or complete week. Usually in this case three's usually something like an "effective date" where it tells you when the rule changes (and one would have to take into account edge cases such as what to do with cases of a "gap" or "overlap" due to the rule change). And of course there may be situation where the rule change may only affect certain departments or divisions within a company. I do recall running into this sort of problem with a customer with a custom report I'd made -- it wasn't until a few iterations of changing the report, then rolling back the change, and re-instating the change and rolling back, that it was discovered that the conflicting requests were the result of different departments that needed the report to operate in their own unique fashion. The eventual solution was to split the report into different versions, with each version customized for the department and labeled in a way so that it was clear which version was for which department.

Thank you for your input. I am taking notes, for the future.