[
https://issues.apache.org/jira/browse/PHOENIX-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-1760:
----------------------------------
Description:
Phoenix DATE and TIME types store 8 byte longs representing epoch time in
milliseconds. If only a lower granularity of time, for example at a granularity
of seconds, is needed, then we could get away storing this in a 4 byte int. One
way to support this would be to have our TIME type allow a precision, much like
we do with CHAR and/or DECIMAL. We could, for example, allow declaration like
this: TIME(6) versus a TIME(9).
When epoch time (in seconds, 4 byte) used in attempt to CAST it AS
TIME/DATE/TIMESTAMP PHOENIX fails with Type mismatch error.
{noformat}
-- 19 Mar 2015 14:46:30 GMT (1426776390 in sec, 1426776390000 in milisec)
select cast(1426776390 AS TIMESTAMP), cast(1426776390000 AS TIMESTAMP) from
system.catalog LIMIT 1;
Error: ERROR 203 (22005): Type mismatch. INTEGER and TIMESTAMP for 1426776390
(state=22005,code=203)
{noformat}
{quote}
The C standard library data type time_t, used on operating systems such as
Unix, is typically implemented as either a 32-bit or a 64-bit signed integer
value, counting the number of seconds since the start of the Unix epoch
(midnight UTC of 1 January 1970). Systems employing a 32-bit type are
susceptible to the Year 2038 problem, so many implementations have moved to a
wider 64-bit type, with a maximal value of 263−1 corresponding to a point in
time 292 billion years from now.
{quote}
was:
When epoch time (in seconds, 4 byte) used in attempt to CAST it AS
TIME/DATE/TIMESTAMP PHOENIX fails with Type mismatch error.
{noformat}
-- 19 Mar 2015 14:46:30 GMT (1426776390 in sec, 1426776390000 in milisec)
select cast(1426776390 AS TIMESTAMP), cast(1426776390000 AS TIMESTAMP) from
system.catalog LIMIT 1;
Error: ERROR 203 (22005): Type mismatch. INTEGER and TIMESTAMP for 1426776390
(state=22005,code=203)
{noformat}
{quote}
The C standard library data type time_t, used on operating systems such as
Unix, is typically implemented as either a 32-bit or a 64-bit signed integer
value, counting the number of seconds since the start of the Unix epoch
(midnight UTC of 1 January 1970). Systems employing a 32-bit type are
susceptible to the Year 2038 problem, so many implementations have moved to a
wider 64-bit type, with a maximal value of 263−1 corresponding to a point in
time 292 billion years from now.
{quote}
> Support type for epoch time in seconds
> --------------------------------------
>
> Key: PHOENIX-1760
> URL: https://issues.apache.org/jira/browse/PHOENIX-1760
> Project: Phoenix
> Issue Type: Bug
> Reporter: Serhiy Bilousov
> Priority: Minor
>
> Phoenix DATE and TIME types store 8 byte longs representing epoch time in
> milliseconds. If only a lower granularity of time, for example at a
> granularity of seconds, is needed, then we could get away storing this in a 4
> byte int. One way to support this would be to have our TIME type allow a
> precision, much like we do with CHAR and/or DECIMAL. We could, for example,
> allow declaration like this: TIME(6) versus a TIME(9).
> When epoch time (in seconds, 4 byte) used in attempt to CAST it AS
> TIME/DATE/TIMESTAMP PHOENIX fails with Type mismatch error.
> {noformat}
> -- 19 Mar 2015 14:46:30 GMT (1426776390 in sec, 1426776390000 in milisec)
> select cast(1426776390 AS TIMESTAMP), cast(1426776390000 AS TIMESTAMP) from
> system.catalog LIMIT 1;
> Error: ERROR 203 (22005): Type mismatch. INTEGER and TIMESTAMP for 1426776390
> (state=22005,code=203)
> {noformat}
> {quote}
> The C standard library data type time_t, used on operating systems such as
> Unix, is typically implemented as either a 32-bit or a 64-bit signed integer
> value, counting the number of seconds since the start of the Unix epoch
> (midnight UTC of 1 January 1970). Systems employing a 32-bit type are
> susceptible to the Year 2038 problem, so many implementations have moved to a
> wider 64-bit type, with a maximal value of 263−1 corresponding to a point in
> time 292 billion years from now.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
