You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by sa...@apache.org on 2018/04/23 17:38:54 UTC
[06/20] impala git commit: IMPALA-6748: [DOCS] Separators when
casting STRING to TIMESTAMP
IMPALA-6748: [DOCS] Separators when casting STRING to TIMESTAMP
Change-Id: Ib82884d5f56c520712c4391b53b799d518d6a54f
Reviewed-on: http://gerrit.cloudera.org:8080/10052
Reviewed-by: Alex Rodoni <ar...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>
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 <ar...@cloudera.com>
Authored: Thu Apr 12 15:52:29 2018 -0700
Committer: Impala Public Jenkins <im...@gerrit.cloudera.org>
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>