Runtime: Implement ISO week numbers

[Sire]

In most of EU and Asia, we have the concept of week numbers. They are defined by an ISO standard (ISO 8601).

ISO week numbers are used by millions of people. For example, the entire medical and school system in Scandinavia, and possibly the entire EU. According to Wikipedia ISO week numbers are used in "EU and most of other European countries, most of Asia and Oceania".

ISO week numbers are still not implemented in .NET Framework, forcing developers to implement workarounds. Also, it's easy to miss that it's not implemented, creating subtle bugs in applications that only appear every 4 years or so.

As a side note, I first reported this as a missing feature to Microsoft in May 2003 when I discovered the problem in .NET Framework v1.0.3705. Celebrating the 14th anniversary of my initial report, I've now considered implementing it myself ;)

Or at least start discussions about implementing it. Because when I started digging into the source code, I fell into a rabbit hole.

The problem is we have to choose between two bad options:

1. Implement ISO week numbers entirely correctly, but possibly breaking stuff. If we're lucky, we're only breaking a few workarounds. This means changing the week rules for various countries implemented in the Framework since the start (from FirstFourDayWeek to ISO).

2. Implement ISO week numbers as an entirely optional feature, only usable when calling the GetWeekOfYear function and always having to explicitly state the ISO week number rule. (We cannot rely on the week rule of the current culture). The actual code changes would be very small with this option.

Am I correct in assuming option 2 is the only realistic one?

(I'm avoiding option 3, to implement nothing).

References:

Microsoft explains the subtle differences between ISO 8601 and GetWeekOfYear()

Week numbers (Wikipedia)

Various workarounds (StackOverflow):
http://stackoverflow.com/a/1497620/
http://stackoverflow.com/a/12197063/
http://stackoverflow.com/a/11155102/
http://stackoverflow.com/a/27791320/

[karelz]

Without knowing any details about it, breaking apps is usually non-starter. If we break stuff, we need to fully understand the impact and ensure the break (which means cost for affected .NET devs) is worth the benefit (which mean overall value for all .NET devs).
Your comment 'If we're lucky' makes me suspicious that I wouldn't like the odds ;-)

Turning subtle bugs for a set of customers into subtle bugs for another set of customers doesn't feel right ...

@tarekgh what are your thoughts? Is it something you have considered in the past?

[Sire]

@karelz I agree :) Let's discuss option 2 then.

[tarekgh]

The ask is reasonable.

we can add extra value to

C# enum CalendarWeekRule
Something like Iso

here is a link for some useful info too.

https://blogs.msdn.microsoft.com/shawnste/2006/01/24/iso-8601-week-of-year-format-in-microsoft-net/

[karelz]

So we need formal API review - see API review process

@Sire interested?

[Sire]

@karelz Yes, I'll get started asap.

[karelz]

Cool. No rush - we will we locked down for new APIs in master until 5/15 - see details in https://github.com/dotnet/corefx/issues/17619#issuecomment-300012102

[danmosemsft]

@Sire did you want to recast the proposal per the example linked to in the api review process above? if so we can take it to review, and if approved, get it implemented.
ping @ me if you have questions.

[khellang]

This can be closed. It's tracked by dotnet/corefx#28933.

[tarekgh]

closed per dotnet/corefx#28933