[ https://issues.apache.org/jira/browse/CALCITE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829339#comment-17829339 ]
Mihai Budiu commented on CALCITE-5155: -------------------------------------- Is there any SQL syntax to define custom time frames? Does any SQL dialect have such syntax that could be added to the Babel parser? > Custom time frames > ------------------ > > Key: CALCITE-5155 > URL: https://issues.apache.org/jira/browse/CALCITE-5155 > Project: Calcite > Issue Type: Bug > Components: core > Reporter: Julian Hyde > Assignee: Julian Hyde > Priority: Major > Labels: pull-request-available > Fix For: 1.33.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > 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.10#820010)