[GitHub] [calcite] wnob commented on pull request #2973: [CALCITE-5180] Implement some of the overloads for BigQuery's DATE and TIMESTAMP
wnob commented on PR #2973: URL: https://github.com/apache/calcite/pull/2973#issuecomment-1322745325 I would also note that both BQ types have microsecond precision, so either way the existing Calcite `TIMESTAMP` is not a perfect match. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [calcite] wnob commented on pull request #2973: [CALCITE-5180] Implement some of the overloads for BigQuery's DATE and TIMESTAMP
wnob commented on PR #2973: URL: https://github.com/apache/calcite/pull/2973#issuecomment-1322739188 Of course, we could simply re-interpret those bits as `DATETIME`, as I mentioned. We don't need a new internal representation; we could just make a new type that happens to have the same internal representation. UTC is not exactly relevant for a BQ timestamp. Sure, the epoch is 1970-01-01 00:00:00 UTC, but you could also think of it as 1969-01-01 16:00:00 PST. It's just a point in time. On the other hand, a time zone would be very relevant if we decided to represent BQ `DATETIME` as a Calcite `TIMESTAMP`, since we would have to interpret Calcite's offset-from-epoch in a particular time zone, UTC being the obvious choice. Alternatively, we could pick a new internal representation for BQ `DATETIME` -- e.g. as a Java `LocalDateTime`, which is internally represented as clock/calendar parameters with no time zone -- and avoid the implementation detail of converting from offset to clock/calendar parameters in a particular time zone. It doesn't really matter from an engineering standpoint. Basically, we have 2 equally possible options: 1. Map BQ `TIMESTAMP` to Calcite `TIMESTAMP`, and map BQ `DATETIME` to something else (probably a whole new type that's BQ-specific, call it `BIGQUERY_DATETIME`) 2. Map BQ `DATETIME` to Calcite `TIMESTAMP`, and map BQ `TIMESTAMP` to something else (also probably a whole new type that's BQ-specific, call it `BIGQUERY_TIMESTAMP`). I just don't see any advantages to option 1 over 2. Option 1 would cause confusion, as well as requiring a slightly awkward internal representation for `DATETIME` because it requires a time zone to convert from internal representation to semantic representation. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [calcite] wnob commented on pull request #2973: [CALCITE-5180] Implement some of the overloads for BigQuery's DATE and TIMESTAMP
wnob commented on PR #2973: URL: https://github.com/apache/calcite/pull/2973#issuecomment-1322705468 > BQ `DATETIME` = Calcite `TIMESTAMP` I don't see the connection. In Calcite, a timestamp is represented internally as an offset in milliseconds since epoch. In BigQuery, a timestamp is represented internally as an offset in microseconds since epoch. Apart from the difference in resolution, they're essentially the same. Of course, this can easily be re-interpreted as a `DATETIME` by assuming a default time zone, but I struggle to see how a Calcite `TIMESTAMP` is better mapped to a BQ `DATETIME` than to a BQ `TIMESTAMP`. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [calcite] wnob commented on pull request #2973: [CALCITE-5180] Implement some of the overloads for BigQuery's DATE and TIMESTAMP
wnob commented on PR #2973: URL: https://github.com/apache/calcite/pull/2973#issuecomment-1320707981 @tjbanghart > Wouldn't `DATETIME` map to Calcite's interpretation of a `TIMESTAMP` due to the lack of TZ info? Neither has tz info. I included a little table in the design doc that shows similarities between types in BQ and Calcite, and BQ `TIMESTAMP` maps pretty well to Calcite's `TIMESTAMP`. There isn't really a good existing type for `DATETIME` in Calcite. I think we'll have to implement one. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [calcite] wnob commented on pull request #2973: [CALCITE-5180] Implement some of the overloads for BigQuery's DATE and TIMESTAMP
wnob commented on PR #2973: URL: https://github.com/apache/calcite/pull/2973#issuecomment-1319428833 I've now implemented all the overloads that do not involve `DATETIME` objects. I'm not sure what is the best way to proceed with these because there doesn't seem to be a good fit in standard SQL to act as an alias. `TIMESTAMP_WITH_LOCAL_TIME_ZONE` is not a great fit; it has an implied time zone, whereas a `DATETIME` has no time zone at all. It's not necessary for MVP since we don't yet support `DATETIME` at all, so I'm inclined to punt on this for now. -- 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: commits-unsubscr...@calcite.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
