Deserializing TimeZoneInfo on Linux throws The Month parameter must be in the range 1 through 12

[o-mdr]

Issue Title

Deserializing TimeZoneInfo on Linux using BinaryFormatter throws The Month parameter must be in the range 1 through 12

General

.net core 2.2, Ubuntu 18 LTS. Please note the same code works fine on Windows. This appears to be a linux specific issue.

I am migrating a library from .net framework 4.7 to .net core 2.2 and found an issue with deep object cloning that I narrowed down to a short reproducible code snippet below.

Try this yourself:

• .net framework 4.7.2 (Pass)
• .net core 2.2 on linux (Fail)

using System;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

namespace Test
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // any zone here, don't care what it is
            var zone = TimeZoneInfo.GetSystemTimeZones()[0];			
            var formatter = new BinaryFormatter();
           
            using (MemoryStream stream = new MemoryStream())
            {
                formatter.Serialize(stream, zone);
                stream.Seek(0, SeekOrigin.Begin);
                var result = formatter.Deserialize(stream); // On Linux, exception is on this line <<<<<
                Console.WriteLine("all ok");
            }
        }
    }
}

On Windows platforms using .net core 2.2 this works fine, but I get an exception on Linux platforms:

Unhandled Exception: System.Runtime.Serialization.SerializationException: An error occurred while deserializing the object.  The serialized data is corrupt. ---> System.ArgumentOutOfRangeException: The Month parameter must be in the range 1 through 12.
Parameter name: month
   at System.TimeZoneInfo.TransitionTime.ValidateTransitionTime(DateTime timeOfDay, Int32 month, Int32 week, Int32 day, DayOfWeek dayOfWeek)
   at System.TimeZoneInfo.TransitionTime.System.Runtime.Serialization.IDeserializationCallback.OnDeserialization(Object sender)
   --- End of inner exception stack trace ---
   at System.TimeZoneInfo.TransitionTime.System.Runtime.Serialization.IDeserializationCallback.OnDeserialization(Object sender)
   at System.Runtime.Serialization.ObjectManager.RaiseDeserializationEvent()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(BinaryParser serParser, Boolean fCheck)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, Boolean check)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)
   at Test.Program.Main(String[] args)

Asked on StackOverflow https://stackoverflow.com/q/57655469/706456

[scalablecory]

@tarekgh

[stephentoub]

cc: @ViktorHofer, @eerhardt

[eerhardt]

@ViktorHofer - I'll take a look at this. My assumption from looking at the code is that the fields are not getting set correctly during deserialization. I assume _month is 0 for some reason:

https://github.com/dotnet/corefx/blob/1841042b99062de13dc80098cede9413be569238/src/Common/src/CoreLib/System/TimeZoneInfo.TransitionTime.cs#L109-L122

[eerhardt]

So I did some debugging (and some reading code to jog my memory), and here's what I found.

When we create TimeZoneInfo's on Unix, we almost always ignore the TransitionTime objects. This is because the way time zones work on Unix is very different than how they work on Windows.

On Windows, we have a couple small rules for each time zone that say how and when the Daylight Savings Time transitions (if any for the zone). The TransitionTime encodes rules like "DST starts on the 3rd Sunday of March", and then we have logic in TimeZoneInfo that interprets these rules.

On Unix, it works differently, and every time there is a DST transition, there is a new AdjustmentRule instance created. On Unix, we set a flag on AdjustmentRule called NoDaylightTransitions, which tells the rest of the logic to ignore any transitions between the Start and End of the AdjustmentRule. Thus, when NoDaylightTransitions is true, the TransitionTime objects are set to default:

https://github.com/dotnet/corefx/blob/fb30a2d1a2bffbba2c039fd294c471962576a2d7/src/Common/src/CoreLib/System/TimeZoneInfo.Unix.cs#L949-L972

So when we serialize a TimeZoneInfo on Unix, these default TransitionTime objects are getting serialized into the stream. Then when they are deserialized, the ValidateTransitionTime method above gets invoked on default instances and it throws because _month, _week, etc are set to 0 which is normally not valid.

The easiest fix I can think of is to check during OnDeserialization if the TransitionTime equals the default, and if it is, skip calling ValidateTransitionTime. We shouldn't change ValidateTransitionTime itself, since it is called from other places that still want to guard against 0 values.

[tarekgh]

The easiest fix I can think of is to check during OnDeserialization if the TransitionTime equals the default, and if it is, skip calling ValidateTransitionTime.

I think this is reasonable as I don't think anyone can create and force default value in their custom rules before serialization.

[eerhardt]

Thanks @tarekgh, I’ll make that PR (and add tests) tomorrow.

[ivmazurenko]

Hello, I have a similar issue in xamarin android project,
dotnet/android#5205

Any chance to avoid this crash? Maybe you have any recommendations?