[
https://issues.apache.org/jira/browse/CALCITE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5155:
---------------------------------
Description:
Allow a type system to define its own time units and how they are rolled up.
Currently, time units are used in the {{EXTRACT}}, {{FLOOR}}, {{TRUNC}}
functions, and include {{YEAR}}, {{QUARTER}}, {{MONTH}}, {{HOUR}}, {{MINUTE}},
{{NANOSECOND}}. For example {{FLOOR(t TO HOUR)}} is valid.
A type system would be allowed to define extra time units. Once a time unit is
defined the {{EXTRACT}}, {{FLOOR}} and {{TRUNC}} functions should just work.
The definition of might consist of a base unit and multiplier. So {{MINUTE15}}
would be based on {{MINUTE}} with a multiplier of 15.
Various rules know that you can roll up {{FLOOR(t TO DAY)}} to {{FLOOR(t TO
MONTH)}} but you cannot roll {{FLOOR(t TO WEEK)}} to {{FLOOR(t TO MONTH)}}.
When you define a new time unit, the type system can deduce that full set of
time units that it can roll up to, and which can roll up to it.
Should we support time units that do not evenly divide the next largest time
unit? For example the number of seconds since the top of the hour modulo 7. 60
and 3,600 are not a multiples of 7, so {{SecondOfHourMod7}} would be different
from {{SecondOfMinuteMod7}}.
was:
Allow a type system to define its own time units and how they are rolled up.
Currently, time units are used in the {{{}EXTRACT{}}}, {{{}FLOOR{}}}, {{TRUNC}}
functions, and include {{{}YEAR{}}}, {{{}QUARTER{}}}, {{{}MONTH{}}},
{{{}HOUR{}}}, {{{}MINUTE{}}}, {{{}NANOSECOND{}}}. For example {{FLOOR(t TO
HOUR)}} is valid.
A type system would be allowed to define extra time units. Once a time unit is
defined the EXTRACT, FLOOR and TRUNC functions should just work.
The definition of might consist of a base unit and multiplier. So MINUTE15
would be based on MINUTE with a multiplier of 15.
Various rules know that you can roll up {{FLOOR(t TO DAY)}} to {{FLOOR(t TO
MONTH)}} but you cannot roll {{FLOOR(t TO WEEK)}} to {{{}FLOOR(t TO MONTH){}}}.
When you define a new time unit, the type system can deduce that full set of
time units that it can roll up to, and which can roll up to it.
Should we support time units that do not evenly divide the next largest time
unit? For example the number of seconds since the top of the hour modulo 7. 60
and 3,600 are not a multiples of 7, so SecondOfHourMod7 would be different from
SecondOfMinuteMod7.
> Extensible time units
> ---------------------
>
> Key: CALCITE-5155
> URL: https://issues.apache.org/jira/browse/CALCITE-5155
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Priority: Major
>
> Allow a type system to define its own time units and how they are rolled up.
> Currently, time units are used in the {{EXTRACT}}, {{FLOOR}}, {{TRUNC}}
> functions, and include {{YEAR}}, {{QUARTER}}, {{MONTH}}, {{HOUR}},
> {{MINUTE}}, {{NANOSECOND}}. For example {{FLOOR(t TO HOUR)}} is valid.
> A type system would be allowed to define extra time units. Once a time unit
> is defined the {{EXTRACT}}, {{FLOOR}} and {{TRUNC}} functions should just
> work.
> The definition of might consist of a base unit and multiplier. So
> {{MINUTE15}} would be based on {{MINUTE}} with a multiplier of 15.
> Various rules know that you can roll up {{FLOOR(t TO DAY)}} to {{FLOOR(t TO
> MONTH)}} but you cannot roll {{FLOOR(t TO WEEK)}} to {{FLOOR(t TO MONTH)}}.
> When you define a new time unit, the type system can deduce that full set of
> time units that it can roll up to, and which can roll up to it.
> Should we support time units that do not evenly divide the next largest time
> unit? For example the number of seconds since the top of the hour modulo 7.
> 60 and 3,600 are not a multiples of 7, so {{SecondOfHourMod7}} would be
> different from {{SecondOfMinuteMod7}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
