System.Datetime is not handled consistently

[TomBruns]

Summary

System.DateTime properties are converted to strings in AVRO
AVRO long > timestamp-millis are generated as System.DateTime POCO class properties

Details

Using create...

Datetime .NET types are generated as a string

dotnet avro create --type System.DateTime
"string"

Using generate...

dotnet avro generate --id 2 --registry-url http://localhost:8081 --registry-config schema.registry.basic.auth.user.info=PLAINTEXT:PLAINTEXT

This fragment of an AVRO definition

      "default": null,
      "name": "Timestamp",
      "type": [
        "null",
        {
          "logicalType": "timestamp-millis",
          "type": "long"
        }
      ]

Generates this C# property

        public global::System.DateTime? Timestamp { get; set; }

Would you accept a PR from my fork?
ex:

.\Chr.Avro.Cli.exe create --type System.DateTime
{"type":"long","logicalType":"timestamp-millis"}

Note: I also added a -f command line option to read the avsc input from a local file. I found that to be easier to use.

-f, --schema-file The full pathname of the avsc schema file on disk.

[dstelljes]

Chr.Avro prefers to map to ISO 8601 strings for the reasons outlined at https://engineering.chrobinson.com/dotnet-avro/internals/mapping/#dates-and-times.

Would you accept a PR from my fork?

We wouldn't accept a PR to change the current behavior, but we would accept a PR to introduce hints on the schema similar to the Java client (see #173).

I also added a -f command line option to read the avsc input from a local file.

The generate command supports piping (see the Generate code from a local schema examples at https://engineering.chrobinson.com/dotnet-avro/cli/generate/), but feel free to submit the -f option in a separate PR if you think it'd be valuable.