You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org> on 2018/01/16 20:53:00 UTC

[jira] [Comment Edited] (CALCITE-2107) Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid

    [ https://issues.apache.org/jira/browse/CALCITE-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327781#comment-16327781 ] 

Jesus Camacho Rodriguez edited comment on CALCITE-2107 at 1/16/18 8:52 PM:
---------------------------------------------------------------------------

OK, I got your point. The only way that I can think of to not rely on session information throughout the optimization is parameterizing the {{timestamp with local time zone}} type?


was (Author: jcamachorodriguez):
OK, I got your point. I have just revisited CALCITE-1947 and it seems to me that we chose to represent {{timestamp with local time zone}} as {{TimestampWithTimeZone}} literal for the same reason, so the information is explicit within the value. For the granularity, this seems a bit more complicated to do. The only way I can think of is parameterizing the {{timestamp with local time zone}} type?

> Timezone not passed as part of granularity when passing TimeExtractionFunction to Druid
> ---------------------------------------------------------------------------------------
>
>                 Key: CALCITE-2107
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2107
>             Project: Calcite
>          Issue Type: Bug
>          Components: druid
>            Reporter: Nishant Bangarwa
>            Assignee: Nishant Bangarwa
>            Priority: Major
>
> When sending granularity to TimeFormatExtractionFunction we need to add timezone to the granularity to align it with the timezone specified in calcite connection. If no timezone is specified in granularity, It is considered as UTC timezone by druid. 
> Note the return value in is as per granularity UTC and not IST as expected  - 
> {code}
>  @Test
>   public void testTmeWithFilterOnFloorOnTimeWithTimezoneConversion() {
>     final String sql = "Select cast(floor(\"timestamp\" to MONTH) as timestamp) as t from "
>         + "\"foodmart\" where floor(\"timestamp\" to MONTH) >= '1997-04-30 18:30:00 UTC' order by t"
>         + " limit 1";
>     final String druidQueryPart1 = "filter\":{\"type\":\"bound\",\"dimension\":\"__time\","
>         + "\"lower\":\"1997-05-01T00:00:00.000Z\",\"lowerStrict\":false,"
>         + "\"ordering\":\"lexicographic\",\"extractionFn\":{\"type\":\"timeFormat\","
>         + "\"format\":\"yyyy-MM-dd";
>     final String druidQueryPart2 = "\"granularity\":\"month\",\"timeZone\":\"IST\","
>         + "\"locale\":\"en-US\"}},\"dimensions\":[],\"metrics\":[],\"granularity\":\"all\"";
>     CalciteAssert.that()
>         .enable(enabled())
>         .with(ImmutableMap.of("model", FOODMART.getPath()))
>         .with(CalciteConnectionProperty.TIME_ZONE.camelName(), "IST")
>         .query(sql)
>         .runs()
>         .queryContains(druidChecker(druidQueryPart1, druidQueryPart2))
>         .returnsOrdered("T=1997-05-01 05:30:00");
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)