AVRO-2818: [ruby] Support ISO 8601 string input in IntDate logical type encode

[abMatGit]

What is the purpose of the change

This pull request partially addresses AVRO-2818 by adding support for encoding ISO 8601 date strings (YYYY-MM-DD) in the Ruby SDK's IntDate logical type.

Previously, IntDate.encode only accepted Numeric or Date/Time objects. Passing a string such as '1970-01-06' would raise a NoMethodError because String#to_date is not part of Ruby's standard library. This change adds a Date.parse call when the input is a String, allowing callers to pass ISO 8601 date strings directly without pre-converting them to Date objects.

Verifying this change

This change added tests and can be verified as follows:

• Extended test_int_date_conversion in test/test_logical_types.rb to assert that ISO 8601 date strings are correctly encoded to their integer day offset from the Unix epoch
  • '1970-01-06' encodes to 5
  • '1970-01-01' encodes to 0

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? not documented

[opwvhk]

Thank you for this addition! Looks simple & clean.

One request: could you please also add the date for -5, like the other tests do?

[martin-g]

My concern with this PR is that it makes the Ruby SDK different than the others.
Maybe the specification should be updated first ?!

[KalleOlaviNiemitalo]

My first thought was this would just be a SDK-specific decision on how language-specific types map to the Avro types, and would be documented in the SDK documentation only, not in the Avro specification.

However, it seems this change could cause ambiguity when encoding a Ruby string value "1970-01-01" using an Avro union schema like

[
    { "type": "int", "logicalType": "date" },
    { "type": "string" }
]

as the string would previously have matched only the second branch of the union, but this change would make it match the first branch too.

In which case the Avro specification should perhaps advise schema authors to avoid defining unions like that. Or the Ruby SDK should provide a way to give the encoder a string that will not be coerced to a date.