fix: separate strptime to fix spec violation

[richtia]

Fix spec violation described in #487 by
separating strptime into strptime_timestamp, strptime_date, and strptime_time

Here's the original PR adding this in case anyone wants to see the discussion
surrounding this addition: #272

[github-actions]

ACTION NEEDED

Substrait follows the Conventional Commits
specification for
release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

[richtia]

ACTION NEEDED

Substrait follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

Hmm...not actually sure why i'm seeing this?

[rok]

Hmm...not actually sure why i'm seeing this?

Maybe try fix(extension): separate stptime to fix spec violation?

[rok]

What about when timezone is present when parsing time and date? Would we want to return those in UTC or local time?

[richtia]

What about when timezone is present when parsing time and date? Would we want to return those in UTC or local time?

Good question. Do you think it would make sense to add another impl to strptime_time and strptime_date that has timezone as a parameter and behave similarly to strptime_timestamp?

[rok]

I think that would work yeah.
We could probably just merge this change as is to fix the current violation and add other variants in separate PR or when needed.

[westonpace]

I agree this is a good change and that impls cannot differ only by return type. We were violating this rule:

It is required that two function implementations with the same simple name must resolve to different compound names using types. If two function implementations in a YAML file resolve to the same compound name, the YAML file is invalid and behavior is undefined.

Given the previous version was not valid I don't think this will count as a backwards incompatible change and we should merge it so we can get moving forwards.

I'll CC @jacques-n and @cpcloud for a posthumous review if/when they have time.