felipecrv commented on issue #3509: URL: https://github.com/apache/arrow-adbc/issues/3509#issuecomment-3363425306
> There needs to be a way to distinguish between "no time zone" (Snowflake's TIMESTAMP_NTZ) and "local time zone" (Snowflake's TIMESTAMP_LTZ). If the Snowflake type is in the metadata then that would probably work for this purpose. I agree that there needs to be a way, but `"Local"` leads to an invalid Arrow type according to the Arrow specification and ecosystem. The standard set of Arrow types doesn't try and doesn't have to match SQL types in all databases. `TIMESTAMP_LTZ` is more about presentation of formatted timestamps than storage. So I would argue the right Arrow type to "store" the LTZ column in memory is `Timestamp(<time_unit>, "UTC")`. If the formatting happens in SQL and the resulting column is a string, the database will format the string in the local timezone. But returning the raw column can be done using an UTC timestamp. > If the Snowflake type is in the metadata then that would probably work for this purpose. Exactly. If the consumer wants to make a distinction between the timestamps returned, it should look at the Arrow field metadata that should contain the original SQL type of the column as a system-specific string. Which is something me and @jasonlin45 are proposing in https://github.com/apache/arrow-adbc/issues/3449 > It arguably makes sense to pass the "local time zone" as a connection string option and substitute that value when present (no matter what the default handling is). That puts implicit connection state into the result sets (the tz field in the Arrow type). Breaks the ability to cache schemas long term. I know that's unavoidable completely, but this creates another dimension of variation in what we get from queries. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
