Inconsistent Behavior for Calendars between macOS on Windows

[vcsjones]

This (bad) code here behaves differently for Windows and macOS:

using System;
using System.Globalization;

class Program
{
    private static CultureInfo _parsingCulture;
    
    static void Main(string[] args)
    {
        _parsingCulture = (CultureInfo)CultureInfo.InvariantCulture.Clone();
        _parsingCulture.DateTimeFormat.Calendar = new AsnUTCTimeCalendar();
        
    }

        private class AsnUTCTimeCalendar : GregorianCalendar
        {
            public override int ToFourDigitYear(int year) => (year < 50 ? 2000 : 1900) + year;
        }
}

On Windows, this throws an exception:

System.InvalidOperationException: Cannot set sub-classed Program+UTCTimeCalendar object to System.Globalization.DateTimeFormatInfo object.

On macOS, an exception is not thrown and it "works".

I understand why the Windows version is throwing, but I was surprised that it did not on macOS. I think the correct behavior is that all platforms should throw the exception.

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64

[danmoseley]

@tarekgh since I'm not sure you watch the coreclr repo area?

[vcsjones]

@danmosemsft Should this have been opened in CoreFX even though the underlying code is in CoreCLR? (asking for future knowledge).

[danmoseley]

@vcsjones good question. We've not been super consistent about that. If it's an API change, since that straddles both, certainly in CoreFX. If it's an implementation change in CoreCLR it gets opened in either and we're ok with that right now. We should look at both.

[tarekgh]

I'll take a look anyway. thanks

[tarekgh]

@vcsjones just to let you know the fix I didn't will make Windows don't throw. the exception throwing was because of the multi-appdomain constraints in the full framework. this condition doesn't exist in coreclr so we shouldn't throw at all.

thanks for bringing this issue.