Date deserialization difference between kestrel on windows and kestrel on macOs/linux

user_1918273 0
Viewed 268

I have tried searching informations on net.core documentation (issue etc) without results. The code is simpler:

    [HttpGet()]
    [Route("dob")]
    public string dobTest()
    {
        var content = @"""1942-01-01T22:00:00.000Z""";
        var settings = new JsonSerializerSettings()
        {
            //DateFormatHandling = DateFormatHandling.IsoDateFormat,
            //DateParseHandling = DateParseHandling.DateTimeOffset,
            DateTimeZoneHandling = DateTimeZoneHandling.Local,
            //DateTimeZoneHandling = DateTimeZoneHandling.RoundtripKind
        };
        var dob = JsonConvert.DeserializeObject<DateTime>(content, settings);

        return $"dob: {dob.ToString("yyyy-MM-dd HH:mm:ss.fff")} - {dob.Kind}";
    }

if I run this code on Mac or Linux the result is:

dob: 1942-01-02 00:00:00.000 - Local

if I run this code on windows the result is:

dob: 1942-01-01 23:00:00.000 - Local

My MacOs timezone is set on Rome(UTC +01:00) Windows timezone is set on Rome(UTC +01:00)

the version of Newtonsoft.Json is 12.0.3 The version of net framework is net core 3.1

asp.net-core-3.1 json-deserialization timezone date c#
1 Answers

Linux and OSX both use the IANA time zone database for its primary source of time zone information, which has correct historical data for time zones in 1942 in Rome, under the identifier Europe/Rome. You can see that UTC+2 is the correct offset for the date given here as well.

Windows, on the other hand, does not have that history for this time zone. The equivalent Windows identifier is W. Europe Standard Time, which has an English display name of (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. You can see the data Windows has in the registry under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\W. Europe Standard Time

If you examine this key using RegEdit, you'll notice that unlike several other time zones, there is no Dynamic DST subkey for this zone. That means Windows is not aware of any historical differences in DST rules, and thus treats every year the under the same set of rules.

Windows does have historical data for some zones, but in general Microsoft only guarantees historical accuracy since 2010 per its DST/TZ support policy.

Thus, if you have the need in your application for historical time zone accuracy, then you should use IANA time zones only. In .NET, you can do this by using TZDB provider in the Noda Time library.

user_6348240
Related