Add DateTimeConverter

[justinyoo]

As discussed in #231 , I'd like to send this PR for DateTimeConverter. It would be great if you have a review and merge it.

What it does are:

• It accepts DateTimeKind.Utc and Standard Date and Time Format Strings of "G" as its default parameters, if they are omitted.
• For deserialisation, it accepts as many number of formats as we want. If a value doesn't match against provided formats, it will return FormatException. Please refer to my whole test cases.
• For serialisation, it only considers the first format in the format list.

Here are examples of usage:

datetime: 2016-12-31 12:34:56

var builder = new DeserializerBuilder()
    .WithNamingConvention(new CamelCateNamingConvention())
    .WithTypeConverter(new DateTimeConverter(DateTimeKind.Utc, new[] { "yyyy-MM-dd HH:mm:ss" });

var deserialiser = builder.Build();

var deserislised = deserialiser.Deserialize<TestObject>(yaml);

var builder = new SerializerBuilder()
    .WithNamingConvention(new CamelCateNamingConvention())
    .WithTypeConverter(new DateTimeConverter(DateTimeKind.Utc, new[] { "yyyy-MM-dd HH:mm:ss" });

var serialiser = builder.Build();

var serialised = serialiser.Serialize(deserialised);

Please note: According to Standard Date and Time Format Strings, there's no difference between "F" and "U", in terms of string representation. Therefore, if both are provided into the converter at the same time, it will return unexpected result.

[aaubry]

Thanks for this. I added a few comments. Can you take a look at them?

[aaubry]

We don't prefix members with underscores in this project. Please remove them to ensure consistency with the codebase.

[justinyoo]

Oh, I overlooked that convention. Sorry about that. I'll remove those underscore prefixes.

[aaubry]

Should we allow to specify the culture that is to be used for reading and writing? What do you think?

[justinyoo]

I also thought about that and concluded to keep invariant culture as I thought it should not be culture-specific.

However, as soon as I read your comment, an idea popped up on top of my head. I'll update the DateTimeConverter class to pass CultureInfo value to handle specific culture, like DateTimeKind value. But I'd still like to keep CultureInfo.InvariantCulture as its default value, if no CultureInfo value is provided. How does it sound to you?

[justinyoo]

@aaubry As requested, I've made some changes.

[justinyoo]

@aaubry Could you run the build at AppVeyor again? It should pass all tests as I ran the test same way as what the build process did. I used xunit.runner.console.2.2.0-beta2-build3300\tools\xunit.console.x86.exe and all tests passed, by the way.

[justinyoo]

@aaubry FYI, I've run this build against my forked branch on AppVeyor and confirm the build passed the test. For some reason, the build process was interrupted at that time.

https://ci.appveyor.com/project/justinyoo/yamldotnet/build/4.0.1-pre1

Could you run the build, https://ci.appveyor.com/project/aaubry/yamldotnet/build/4.0.1-pre314, again at your end, please?

[aaubry]

I was unable to reply sooner, sorry. I ran the tests locally and the test fails occasionally. But if I run the tests again, they pass. I'm not really sure what's going on, but I'll investigate further.

[aaubry]

I have updated FakeItEasy to version 2.3.3 and now it seems that the tests always pass.
I'll do a release soon that will include this change. Thanks

[aaubry]

Hi, @justinyoo, I noticed recently, while working on #255, that some of the DateTime tests fail on Linux with Mono. I had to comment out some of them, apparently the ones that use the Korean AM/PM designator. I thought that maybe you knew of a workaround? Thanks

[justinyoo]

@aaubry ORLY? Yeah, for now you can comment that out. Seems that tests only fail where AM/PM designator exists. I'll have a look.