[SIG-45543] return microsecond rather than nanosec in arrowToRecord() for timestamp tz/ntz/ltz to avoid future date overflow

[Yifeng-Sigma]

Description

snowflakedb#910
The last piece that blocks arrow batch.
It's the "Year 2262" problem.
The root cause is the int64, which is the underlying data representation of arrow.Timestamp() is unable to support date beyond 2262 in nanosecond.
timestampNtzType, timestampLtzType, timestampTzType from snowflake can return a future date that can't be represented by int64 in nanosecond.

Since in Sigma system we use millisecond for now and there's microsecond WIP, we don't have any plans to support nanosecond. We can just transport microsecond in arrow batch to bypass this problem.

This only affects arrow batch path and doesn't have impact on production code.
I'll also make exporter/evaluator changes.

Question You Might Ask

Why we don't we use upstream fix?
There is no "real fix" to the problem. What upstream does is to add a validation check and return an error if overflow. However since we don't need nanosecond, we can return microsecond and bypass this year 2262 problem at all.

Checklist

• Code compiles correctly
• Run make fmt to fix inconsistent formats
• Run make lint to get lint errors and fix all of them
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary

[madisonchamberlain]

LGTM I will keep this change in mind for what is needed for to work on to have more parity with the non forked version

[Yifeng-Sigma]

LGTM I will keep this change in mind for what is needed for to work on to have more parity with the non forked version

Thanks! We can chat more when you start the new connector work. Happy to help on the arrow batch part.