IMPALA-6748: [DOCS] Separators when casting STRING to TIMESTAMP Change-Id: Ib82884d5f56c520712c4391b53b799d518d6a54f Reviewed-on: http://gerrit.cloudera.org:8080/10052 Reviewed-by: Alex Rodoni <[email protected]> Tested-by: Impala Public Jenkins <[email protected]>
Project: http://git-wip-us.apache.org/repos/asf/impala/repo Commit: http://git-wip-us.apache.org/repos/asf/impala/commit/5f4d89f8 Tree: http://git-wip-us.apache.org/repos/asf/impala/tree/5f4d89f8 Diff: http://git-wip-us.apache.org/repos/asf/impala/diff/5f4d89f8 Branch: refs/heads/2.x Commit: 5f4d89f86cdf79bc4f718ac654ced17c67b93ce3 Parents: dff44e4 Author: Alex Rodoni <[email protected]> Authored: Thu Apr 12 15:52:29 2018 -0700 Committer: Impala Public Jenkins <[email protected]> Committed: Thu Apr 19 22:10:21 2018 +0000 ---------------------------------------------------------------------- docs/shared/impala_common.xml | 44 +++++- docs/topics/impala_timestamp.xml | 245 ++++++++++++++++++++-------------- 2 files changed, 182 insertions(+), 107 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/impala/blob/5f4d89f8/docs/shared/impala_common.xml ---------------------------------------------------------------------- diff --git a/docs/shared/impala_common.xml b/docs/shared/impala_common.xml index e651337..1d6ef1f 100644 --- a/docs/shared/impala_common.xml +++ b/docs/shared/impala_common.xml @@ -1328,12 +1328,44 @@ drop database temp; </p> <p id="timestamp_conversions"> - Impala automatically converts <codeph>STRING</codeph> literals of the correct format into - <codeph>TIMESTAMP</codeph> values. Timestamp values are accepted in the format - <codeph>"yyyy-MM-dd HH:mm:ss.SSSSSS"</codeph>, and can consist of just the date, or just the time, with or - without the fractional second portion. For example, you can specify <codeph>TIMESTAMP</codeph> values such as - <codeph>'1966-07-30'</codeph>, <codeph>'08:30:00'</codeph>, or <codeph>'1985-09-25 17:45:30.005'</codeph>. - <ph conref="../shared/impala_common.xml#common/cast_int_to_timestamp"/> + Impala automatically converts <codeph>STRING</codeph> literals of the + correct format into <codeph>TIMESTAMP</codeph> values. Timestamp values + are accepted in the format <codeph>"yyyy-MM-dd HH:mm:ss.SSSSSS"</codeph>, + and can consist of just the date, or just the time, with or without the + fractional second portion. For example, you can specify <codeph>TIMESTAMP</codeph> + values such as <codeph>'1966-07-30'</codeph>, <codeph>'08:30:00'</codeph>, + or <codeph>'1985-09-25 17:45:30.005'</codeph>. + </p> + <p>Leading zeroes are not required in the numbers representing the date + component, such as month and date, or the time component, such as + month, date, hour, minute, second. For example, Impala accepts both + <codeph>"2018-1-1 01:02:03"</codeph> and + <codeph>"2018-01-01 1:2:3"</codeph> as valid.</p> + + <p id="cast_string_to_timestamp"> + When you convert or cast a <codeph>STRING</codeph> literal to <codeph>TIMESTAMP</codeph>, + you can use the following separators between the date part and the time part: + <ul> + <li> + <p> + One or more space characters + </p> + + <p> + Example: <codeph>CAST ('2001-01-09 01:05:01' AS TIMESTAMP)</codeph> + </p> + </li> + + <li> + <p> + The character âTâ + </p> + + <p> + Example: <codeph>CAST ('2001-01-09T01:05:01' AS TIMESTAMP)</codeph> + </p> + </li> + </ul> </p> <p> http://git-wip-us.apache.org/repos/asf/impala/blob/5f4d89f8/docs/topics/impala_timestamp.xml ---------------------------------------------------------------------- diff --git a/docs/topics/impala_timestamp.xml b/docs/topics/impala_timestamp.xml index 320f99d..d032e33 100644 --- a/docs/topics/impala_timestamp.xml +++ b/docs/topics/impala_timestamp.xml @@ -21,7 +21,13 @@ under the License. <concept id="timestamp"> <title>TIMESTAMP Data Type</title> - <titlealts audience="PDF"><navtitle>TIMESTAMP</navtitle></titlealts> + + <titlealts audience="PDF"> + + <navtitle>TIMESTAMP</navtitle> + + </titlealts> + <prolog> <metadata> <data name="Category" value="Impala"/> @@ -36,8 +42,8 @@ under the License. <conbody> <p> - A data type used in <codeph>CREATE TABLE</codeph> and <codeph>ALTER TABLE</codeph> statements, representing a - point in time. + A data type used in <codeph>CREATE TABLE</codeph> and <codeph>ALTER TABLE</codeph> + statements, representing a point in time. </p> <p conref="../shared/impala_common.xml#common/syntax_blurb"/> @@ -49,9 +55,9 @@ under the License. <codeblock><varname>column_name</varname> TIMESTAMP</codeblock> <p> - <b>Range:</b> Allowed date values range from 1400-01-01 to 9999-12-31; this range is different from the Hive - <codeph>TIMESTAMP</codeph> type. Internally, the resolution of the time portion of a - <codeph>TIMESTAMP</codeph> value is in nanoseconds. + <b>Range:</b> Allowed date values range from 1400-01-01 to 9999-12-31; this range is + different from the Hive <codeph>TIMESTAMP</codeph> type. Internally, the resolution of the + time portion of a <codeph>TIMESTAMP</codeph> value is in nanoseconds. </p> <p> @@ -59,16 +65,18 @@ under the License. </p> <p> - You can perform date arithmetic by adding or subtracting a specified number of time units, using the - <codeph>INTERVAL</codeph> keyword and the <codeph>+</codeph> and <codeph>-</codeph> operators or - <codeph>date_add()</codeph> and <codeph>date_sub()</codeph> functions. You can specify units as - <codeph>YEAR[S]</codeph>, <codeph>MONTH[S]</codeph>, <codeph>WEEK[S]</codeph>, <codeph>DAY[S]</codeph>, + You can perform date arithmetic by adding or subtracting a specified number of time units, + using the <codeph>INTERVAL</codeph> keyword and the <codeph>+</codeph> and + <codeph>-</codeph> operators or <codeph>date_add()</codeph> and + <codeph>date_sub()</codeph> functions. You can specify units as <codeph>YEAR[S]</codeph>, + <codeph>MONTH[S]</codeph>, <codeph>WEEK[S]</codeph>, <codeph>DAY[S]</codeph>, <codeph>HOUR[S]</codeph>, <codeph>MINUTE[S]</codeph>, <codeph>SECOND[S]</codeph>, - <codeph>MILLISECOND[S]</codeph>, <codeph>MICROSECOND[S]</codeph>, and <codeph>NANOSECOND[S]</codeph>. You can - only specify one time unit in each interval expression, for example <codeph>INTERVAL 3 DAYS</codeph> or - <codeph>INTERVAL 25 HOURS</codeph>, but you can produce any granularity by adding together successive - <codeph>INTERVAL</codeph> values, such as <codeph><varname>timestamp_value</varname> + INTERVAL 3 WEEKS - - INTERVAL 1 DAY + INTERVAL 10 MICROSECONDS</codeph>. + <codeph>MILLISECOND[S]</codeph>, <codeph>MICROSECOND[S]</codeph>, and + <codeph>NANOSECOND[S]</codeph>. You can only specify one time unit in each interval + expression, for example <codeph>INTERVAL 3 DAYS</codeph> or <codeph>INTERVAL 25 + HOURS</codeph>, but you can produce any granularity by adding together successive + <codeph>INTERVAL</codeph> values, such as <codeph><varname>timestamp_value</varname> + + INTERVAL 3 WEEKS - INTERVAL 1 DAY + INTERVAL 10 MICROSECONDS</codeph>. </p> <p> @@ -86,34 +94,39 @@ insert into auction_details </p> <p> - By default, Impala does not store timestamps using the local timezone, to avoid undesired results from - unexpected time zone issues. Timestamps are stored and interpreted relative to UTC, both when written to or - read from data files, or when converted to or from Unix time values through functions such as - <codeph>from_unixtime()</codeph> or <codeph>unix_timestamp()</codeph>. To convert such a - <codeph>TIMESTAMP</codeph> value to one that represents the date and time in a specific time zone, convert - the original value with the <codeph>from_utc_timestamp()</codeph> function. + By default, Impala does not store timestamps using the local timezone, to avoid undesired + results from unexpected time zone issues. Timestamps are stored and interpreted relative + to UTC, both when written to or read from data files, or when converted to or from Unix + time values through functions such as <codeph>from_unixtime()</codeph> or + <codeph>unix_timestamp()</codeph>. To convert such a <codeph>TIMESTAMP</codeph> value to + one that represents the date and time in a specific time zone, convert the original value + with the <codeph>from_utc_timestamp()</codeph> function. </p> <p> - Because Impala does not assume that <codeph>TIMESTAMP</codeph> values are in any particular time zone, you - must be conscious of the time zone aspects of data that you query, insert, or convert. + Because Impala does not assume that <codeph>TIMESTAMP</codeph> values are in any + particular time zone, you must be conscious of the time zone aspects of data that you + query, insert, or convert. </p> <p> - For consistency with Unix system calls, the <codeph>TIMESTAMP</codeph> returned by the <codeph>now()</codeph> - function represents the local time in the system time zone, rather than in UTC. To store values relative to - the current time in a portable way, convert any <codeph>now()</codeph> return values using the - <codeph>to_utc_timestamp()</codeph> function first. For example, the following example shows that the current - time in California (where this Impala cluster is located) is shortly after 2 PM. If that value was written to a data - file, and shipped off to a distant server to be analyzed alongside other data from far-flung locations, the - dates and times would not match up precisely because of time zone differences. Therefore, the - <codeph>to_utc_timestamp()</codeph> function converts it using a common reference point, the UTC time zone - (descended from the old Greenwich Mean Time standard). The <codeph>'PDT'</codeph> argument indicates that the - original value is from the Pacific time zone with Daylight Saving Time in effect. When servers in all - geographic locations run the same transformation on any local date and time values (with the appropriate time - zone argument), the stored data uses a consistent representation. Impala queries can use functions such as - <codeph>EXTRACT()</codeph>, <codeph>MIN()</codeph>, <codeph>AVG()</codeph>, and so on to do time-series - analysis on those timestamps. + For consistency with Unix system calls, the <codeph>TIMESTAMP</codeph> returned by the + <codeph>now()</codeph> function represents the local time in the system time zone, rather + than in UTC. To store values relative to the current time in a portable way, convert any + <codeph>now()</codeph> return values using the <codeph>to_utc_timestamp()</codeph> + function first. For example, the following example shows that the current time in + California (where this Impala cluster is located) is shortly after 2 PM. If that value was + written to a data file, and shipped off to a distant server to be analyzed alongside other + data from far-flung locations, the dates and times would not match up precisely because of + time zone differences. Therefore, the <codeph>to_utc_timestamp()</codeph> function + converts it using a common reference point, the UTC time zone (descended from the old + Greenwich Mean Time standard). The <codeph>'PDT'</codeph> argument indicates that the + original value is from the Pacific time zone with Daylight Saving Time in effect. When + servers in all geographic locations run the same transformation on any local date and time + values (with the appropriate time zone argument), the stored data uses a consistent + representation. Impala queries can use functions such as <codeph>EXTRACT()</codeph>, + <codeph>MIN()</codeph>, <codeph>AVG()</codeph>, and so on to do time-series analysis on + those timestamps. </p> <codeblock>[localhost:21000] > select now(); @@ -131,12 +144,14 @@ insert into auction_details </codeblock> <p> - The converse function, <codeph>from_utc_timestamp()</codeph>, lets you take stored <codeph>TIMESTAMP</codeph> - data or calculated results and convert back to local date and time for processing on the application side. - The following example shows how you might represent some future date (such as the ending date and time of an - auction) in UTC, and then convert back to local time when convenient for reporting or other processing. The - final query in the example tests whether this arbitrary UTC date and time has passed yet, by converting it - back to the local time zone and comparing it against the current date and time. + The converse function, <codeph>from_utc_timestamp()</codeph>, lets you take stored + <codeph>TIMESTAMP</codeph> data or calculated results and convert back to local date and + time for processing on the application side. The following example shows how you might + represent some future date (such as the ending date and time of an auction) in UTC, and + then convert back to local time when convenient for reporting or other processing. The + final query in the example tests whether this arbitrary UTC date and time has passed yet, + by converting it back to the local time zone and comparing it against the current date and + time. </p> <codeblock>[localhost:21000] > select to_utc_timestamp(now() + interval 2 weeks, 'PDT'); @@ -160,35 +175,42 @@ insert into auction_details </codeblock> <p rev="2.2.0"> - If you have data files written by Hive, those <codeph>TIMESTAMP</codeph> values represent the local timezone - of the host where the data was written, potentially leading to inconsistent results when processed by Impala. - To avoid compatibility problems or having to code workarounds, you can specify one or both of these - <cmdname>impalad</cmdname> startup flags: <codeph>--use_local_tz_for_unix_timestamp_conversions=true</codeph> + If you have data files written by Hive, those <codeph>TIMESTAMP</codeph> values represent + the local timezone of the host where the data was written, potentially leading to + inconsistent results when processed by Impala. To avoid compatibility problems or having + to code workarounds, you can specify one or both of these <cmdname>impalad</cmdname> + startup flags: <codeph>--use_local_tz_for_unix_timestamp_conversions=true</codeph> <codeph>-convert_legacy_hive_parquet_utc_timestamps=true</codeph>. Although - <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> is turned off by default to avoid performance overhead, where practical - turn it on when processing <codeph>TIMESTAMP</codeph> columns in Parquet files written by Hive, to avoid unexpected behavior. + <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> is turned off by default to + avoid performance overhead, where practical turn it on when processing + <codeph>TIMESTAMP</codeph> columns in Parquet files written by Hive, to avoid unexpected + behavior. </p> <p rev="2.2.0"> - The <codeph>--use_local_tz_for_unix_timestamp_conversions</codeph> setting affects conversions from - <codeph>TIMESTAMP</codeph> to <codeph>BIGINT</codeph>, or from <codeph>BIGINT</codeph> - to <codeph>TIMESTAMP</codeph>. By default, Impala treats all <codeph>TIMESTAMP</codeph> values as UTC, - to simplify analysis of time-series data from different geographic regions. When you enable the + The <codeph>--use_local_tz_for_unix_timestamp_conversions</codeph> setting affects + conversions from <codeph>TIMESTAMP</codeph> to <codeph>BIGINT</codeph>, or from + <codeph>BIGINT</codeph> to <codeph>TIMESTAMP</codeph>. By default, Impala treats all + <codeph>TIMESTAMP</codeph> values as UTC, to simplify analysis of time-series data from + different geographic regions. When you enable the <codeph>--use_local_tz_for_unix_timestamp_conversions</codeph> setting, these operations - treat the input values as if they are in the local tie zone of the host doing the processing. - See <xref href="impala_datetime_functions.xml#datetime_functions"/> for the list of functions - affected by the <codeph>--use_local_tz_for_unix_timestamp_conversions</codeph> setting. + treat the input values as if they are in the local tie zone of the host doing the + processing. See <xref + href="impala_datetime_functions.xml#datetime_functions"/> + for the list of functions affected by the + <codeph>--use_local_tz_for_unix_timestamp_conversions</codeph> setting. </p> <p> - The following sequence of examples shows how the interpretation of <codeph>TIMESTAMP</codeph> values in - Parquet tables is affected by the setting of the <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> - setting. + The following sequence of examples shows how the interpretation of + <codeph>TIMESTAMP</codeph> values in Parquet tables is affected by the setting of the + <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> setting. </p> <p> Regardless of the <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> setting, - <codeph>TIMESTAMP</codeph> columns in text tables can be written and read interchangeably by Impala and Hive: + <codeph>TIMESTAMP</codeph> columns in text tables can be written and read interchangeably + by Impala and Hive: </p> <codeblock>Impala DDL and queries for text table: @@ -220,11 +242,12 @@ Time taken: 1.245 seconds, Fetched: 2 row(s) </codeblock> <p> - When the table uses Parquet format, Impala expects any time zone adjustment to be applied prior to writing, - while <codeph>TIMESTAMP</codeph> values written by Hive are adjusted to be in the UTC time zone. When Hive - queries Parquet data files that it wrote, it adjusts the <codeph>TIMESTAMP</codeph> values back to the local - time zone, while Impala does no conversion. Hive does no time zone conversion when it queries Impala-written - Parquet files. + When the table uses Parquet format, Impala expects any time zone adjustment to be applied + prior to writing, while <codeph>TIMESTAMP</codeph> values written by Hive are adjusted to + be in the UTC time zone. When Hive queries Parquet data files that it wrote, it adjusts + the <codeph>TIMESTAMP</codeph> values back to the local time zone, while Impala does no + conversion. Hive does no time zone conversion when it queries Impala-written Parquet + files. </p> <codeblock>Impala DDL and queries for Parquet table: @@ -264,10 +287,11 @@ Time taken: 0.197 seconds, Fetched: 2 row(s) </codeblock> <p> - The discrepancy arises when Impala queries the Hive-created Parquet table. The underlying values in the - <codeph>TIMESTAMP</codeph> column are different from the ones written by Impala, even though they were copied - from one table to another by an <codeph>INSERT ... SELECT</codeph> statement in Hive. Hive did an implicit - conversion from the local time zone to UTC as it wrote the values to Parquet. + The discrepancy arises when Impala queries the Hive-created Parquet table. The underlying + values in the <codeph>TIMESTAMP</codeph> column are different from the ones written by + Impala, even though they were copied from one table to another by an <codeph>INSERT ... + SELECT</codeph> statement in Hive. Hive did an implicit conversion from the local time + zone to UTC as it wrote the values to Parquet. </p> <codeblock>Impala query for TIMESTAMP values from Impala-written and Hive-written data: @@ -310,11 +334,12 @@ Fetched 2 row(s) in 0.20s </codeblock> <p> - When the <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> setting is enabled, Impala recognizes - the Parquet data files written by Hive, and applies the same UTC-to-local-timezone conversion logic during - the query as Hive uses, making the contents of the Impala-written <codeph>P1</codeph> table and the - Hive-written <codeph>H1</codeph> table appear identical, whether represented as <codeph>TIMESTAMP</codeph> - values or the underlying <codeph>BIGINT</codeph> integers: + When the <codeph>-convert_legacy_hive_parquet_utc_timestamps</codeph> setting is enabled, + Impala recognizes the Parquet data files written by Hive, and applies the same + UTC-to-local-timezone conversion logic during the query as Hive uses, making the contents + of the Impala-written <codeph>P1</codeph> table and the Hive-written <codeph>H1</codeph> + table appear identical, whether represented as <codeph>TIMESTAMP</codeph> values or the + underlying <codeph>BIGINT</codeph> integers: </p> <codeblock>[localhost:21000] > select x from p1; @@ -355,14 +380,23 @@ Fetched 2 row(s) in 0.22s <b>Conversions:</b> </p> - <p conref="../shared/impala_common.xml#common/timestamp_conversions"/> + <p conref="../shared/impala_common.xml#common/timestamp_conversions" + conrefend="../shared/impala_common.xml#common/cast_string_to_timestamp"/> <p> - In Impala 1.3 and higher, the <codeph>FROM_UNIXTIME()</codeph> and <codeph>UNIX_TIMESTAMP()</codeph> - functions allow a wider range of format strings, with more flexibility in element order, repetition of letter - placeholders, and separator characters. In <keyword keyref="impala23_full"/> and higher, the <codeph>UNIX_TIMESTAMP()</codeph> - function also allows a numeric timezone offset to be specified as part of the input string. - See <xref href="impala_datetime_functions.xml#datetime_functions"/> for details. + <ph conref="../shared/impala_common.xml#common/cast_int_to_timestamp"/> + </p> + + <p> + In Impala 1.3 and higher, the <codeph>FROM_UNIXTIME()</codeph> and + <codeph>UNIX_TIMESTAMP()</codeph> functions allow a wider range of format strings, with + more flexibility in element order, repetition of letter placeholders, and separator + characters. In <keyword + keyref="impala23_full"/> and higher, the + <codeph>UNIX_TIMESTAMP()</codeph> function also allows a numeric timezone offset to be + specified as part of the input string. See + <xref + href="impala_datetime_functions.xml#datetime_functions"/> for details. </p> <p conref="../shared/impala_common.xml#common/y2k38"/> @@ -372,11 +406,13 @@ Fetched 2 row(s) in 0.22s </p> <p> - Although you cannot use a <codeph>TIMESTAMP</codeph> column as a partition key, you can extract the - individual years, months, days, hours, and so on and partition based on those columns. Because the partition - key column values are represented in HDFS directory names, rather than as fields in the data files - themselves, you can also keep the original <codeph>TIMESTAMP</codeph> values if desired, without duplicating - data or wasting storage space. See <xref href="impala_partitioning.xml#partition_key_columns"/> for more + Although you cannot use a <codeph>TIMESTAMP</codeph> column as a partition key, you can + extract the individual years, months, days, hours, and so on and partition based on those + columns. Because the partition key column values are represented in HDFS directory names, + rather than as fields in the data files themselves, you can also keep the original + <codeph>TIMESTAMP</codeph> values if desired, without duplicating data or wasting storage + space. See <xref + href="impala_partitioning.xml#partition_key_columns"/> for more details on partitioning with date and time values. </p> @@ -409,21 +445,23 @@ ERROR: AnalysisException: Type 'TIMESTAMP' is not supported as partition-column <p conref="../shared/impala_common.xml#common/restrictions_blurb"/> <p> - If you cast a <codeph>STRING</codeph> with an unrecognized format to a <codeph>TIMESTAMP</codeph>, the result - is <codeph>NULL</codeph> rather than an error. Make sure to test your data pipeline to be sure any textual - date and time values are in a format that Impala <codeph>TIMESTAMP</codeph> can recognize. + If you cast a <codeph>STRING</codeph> with an unrecognized format to a + <codeph>TIMESTAMP</codeph>, the result is <codeph>NULL</codeph> rather than an error. Make + sure to test your data pipeline to be sure any textual date and time values are in a + format that Impala <codeph>TIMESTAMP</codeph> can recognize. </p> <p conref="../shared/impala_common.xml#common/avro_no_timestamp"/> <p conref="../shared/impala_common.xml#common/kudu_blurb"/> + <p conref="../shared/impala_common.xml#common/kudu_timestamp_details"/> <p conref="../shared/impala_common.xml#common/example_blurb"/> <p> - The following examples demonstrate using <codeph>TIMESTAMP</codeph> values - with built-in functions: + The following examples demonstrate using <codeph>TIMESTAMP</codeph> values with built-in + functions: </p> <codeblock>select cast('1966-07-30' as timestamp); @@ -441,8 +479,8 @@ select now(); -- Returns current date and time in </codeblock> <p> - The following examples demonstrate using <codeph>TIMESTAMP</codeph> values - with HDFS-backed tables: + The following examples demonstrate using <codeph>TIMESTAMP</codeph> values with + HDFS-backed tables: </p> <codeblock>create table dates_and_times (t timestamp); @@ -451,8 +489,8 @@ insert into dates_and_times values </codeblock> <p rev="IMPALA-5137"> - The following examples demonstrate using <codeph>TIMESTAMP</codeph> values - with Kudu tables: + The following examples demonstrate using <codeph>TIMESTAMP</codeph> values with Kudu + tables: </p> <codeblock rev="IMPALA-5137">create table timestamp_t (x int primary key, s string, t timestamp, b bigint) @@ -495,16 +533,21 @@ select s, t, b from timestamp_t order by t; </li> <li> - To convert to or from different date formats, or perform date arithmetic, use the date and time functions - described in <xref href="impala_datetime_functions.xml#datetime_functions"/>. In particular, the - <codeph>from_unixtime()</codeph> function requires a case-sensitive format string such as - <codeph>"yyyy-MM-dd HH:mm:ss.SSSS"</codeph>, matching one of the allowed variations of a - <codeph>TIMESTAMP</codeph> value (date plus time, only date, only time, optional fractional seconds). + To convert to or from different date formats, or perform date arithmetic, use the date + and time functions described in + <xref + href="impala_datetime_functions.xml#datetime_functions"/>. In + particular, the <codeph>from_unixtime()</codeph> function requires a case-sensitive + format string such as <codeph>"yyyy-MM-dd HH:mm:ss.SSSS"</codeph>, matching one of the + allowed variations of a <codeph>TIMESTAMP</codeph> value (date plus time, only date, + only time, optional fractional seconds). </li> <li> - See <xref href="impala_langref_unsupported.xml#langref_hiveql_delta"/> for details about differences in - <codeph>TIMESTAMP</codeph> handling between Impala and Hive. + See <xref href="impala_langref_unsupported.xml#langref_hiveql_delta" + /> for + details about differences in <codeph>TIMESTAMP</codeph> handling between Impala and + Hive. </li> </ul>
