In discussion about IMPALA-5607, it came up that implementing this as described is a compatibility breaking change. There are a couple of required changes:
1) Return data type for date_part and EXTRACT FROM must be promoted to BIGINT. 2) MILLISECONDS now will include seconds part in the calculation of milliseconds. I think the first is a non-issue; we're promoting the type to be wide enough to hold nanoseconds precision values (with the seconds component included). An alternative could be to return this as a decimal type, but that seems rather unwieldy for other date expressions so I'd prefer these values to all be returned as integral types. The bigger issue is including seconds in the calculation of milliseconds, microseconds and nanoseconds breaks the existing value returned for milliseconds, which is just bare milliseconds with no seconds component. For compatibility with other SQL implementations, I think we'd like to include seconds with all of these date parts, but that is certainly debatable. The question then, is anyone relying on this functionality that can't easily workaround such a change? The Impala documentation doesn't specify this behavior either way, and there isn't a formal specification for how sub-second granularity time is handled. Whatever we decide, we should document this going forward. - Zach
