[ https://issues.apache.org/jira/browse/CALCITE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603224#comment-17603224 ]
Justin Swett commented on CALCITE-5155: --------------------------------------- Re 5: Do we need an offset parameter to derive a useful name? E.g. weeks can start on Sunday vs Monday, or the notion of a fiscal year can vary depending on sector. > 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.10#820010)