davidhcoe opened a new issue, #2811:
URL: https://github.com/apache/arrow-adbc/issues/2811
### What happened?
If you run the query for
```
select TO_TIMESTAMP('9999-12-31 00:00:00') As December31,
TO_TIMESTAMP('9999-12-30 00:00:00') As December30"
```
You get incorrect values because the epoch from Snowflake () gets converted
to -4852202631933722624, which is actually March 29, 1816 at 05:56:08.066278.
I believe this is because during the call to:
```
v, err := arrow.TimestampFromTime(time.Unix(epoch[i], int64(fraction[i])),
dt.TimeUnit())
```
The correct epoch value gets passed in, but with the TimeUnit of
Nanoseconds, the internals of TimestampFromTime convert the large epoch value
to nanoseconds again, causing the int64 value to overflow to the negative
number:
```
func TimestampFromTime(val time.Time, unit TimeUnit) (Timestamp, error) {
switch unit {
case Second:
return Timestamp(val.Unix()), nil
case Millisecond:
return Timestamp(val.Unix()*1e3 + int64(val.Nanosecond())/1e6),
nil
case Microsecond:
return Timestamp(val.Unix()*1e6 + int64(val.Nanosecond())/1e3),
nil
case Nanosecond:
**return Timestamp(val.UnixNano()), nil** // <-- problematic
line
default:
return 0, fmt.Errorf("%w: unexpected timestamp unit: %s",
ErrInvalid, unit)
}
}
```
However, the Time value already comes in at the correct date. I am working
on a proposed fix.
### Stack Trace
_No response_
### How can we reproduce the bug?
_No response_
### Environment/Setup
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
