Influx aggregation query return wrong time












2














I'm a new influxdb user and my influxDB version is 1.7.1. I have problem with time in influx.



I have a measurement called lv_table, Listing_id and event_type are tags and event_id is field






select *  from "lv_table" limit 10 
name: lv_table
time Listing_id event_id event_type
---- ---------- -------- ----------
1542711774019000 105202696 4 "leads"
1542711774020000 105497566 66 "view"
1542711774021000 95532296 66 "view"
1542711774021000 98830991 1 "leads"
1542711774022000 105456186 66 "view"
1542711774023000 94326731 66 "view"
1542711774025000 104584666 66 "view"
1542711774028000 105603346 66 "view"
1542711774035000 99913981 66 "view"
1542711774037000 105430516 3 "leads"





but when I use "precision RFC3339" in cli, that query return date in 1970 year like '1970-01-18T20:31:51.774019Z' but correct time is '2018-11-20T20:31:51.774019Z'






> precision RFC3339
> select * from "lv_table" limit 10
name: lv_table
time Listing_id event_id event_type
---- ---------- -------- ----------
1970-01-18T20:31:51.774019Z 105202696 4 "leads"
1970-01-18T20:31:51.77402Z 105497566 66 "view"
1970-01-18T20:31:51.774021Z 95532296 66 "view"
1970-01-18T20:31:51.774021Z 98830991 1 "leads"
1970-01-18T20:31:51.774022Z 105456186 66 "view"
1970-01-18T20:31:51.774023Z 94326731 66 "view"
1970-01-18T20:31:51.774025Z 104584666 66 "view"
1970-01-18T20:31:51.774028Z 105603346 66 "view"
1970-01-18T20:31:51.774035Z 99913981 66 "view"
1970-01-18T20:31:51.774037Z 105430516 1 "leads"
>





What's the problem and how can I fix it?



In aggregation query it gets worth ... and show time in 2016 but it should be in 2018-11-20 date



1468800000000000 = Monday, July 18, 2016 12:00:00 AM






select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
>...
name: lv_table
tags: Listing_id=99965506
time count_leads_event_id
---- --------------------
1468800000000000 1

name: lv_table
tags: Listing_id=99965771
time count_leads_event_id
---- --------------------
1468800000000000 2

name: lv_table
tags: Listing_id=99966146
time count_leads_event_id
---- --------------------
1468800000000000 1

name: lv_table
tags: Listing_id=99966736
time count_leads_event_id
---- --------------------
1468800000000000 3
...





If I don't use group by on time, time will be equal 0










share|improve this question





























    2














    I'm a new influxdb user and my influxDB version is 1.7.1. I have problem with time in influx.



    I have a measurement called lv_table, Listing_id and event_type are tags and event_id is field






    select *  from "lv_table" limit 10 
    name: lv_table
    time Listing_id event_id event_type
    ---- ---------- -------- ----------
    1542711774019000 105202696 4 "leads"
    1542711774020000 105497566 66 "view"
    1542711774021000 95532296 66 "view"
    1542711774021000 98830991 1 "leads"
    1542711774022000 105456186 66 "view"
    1542711774023000 94326731 66 "view"
    1542711774025000 104584666 66 "view"
    1542711774028000 105603346 66 "view"
    1542711774035000 99913981 66 "view"
    1542711774037000 105430516 3 "leads"





    but when I use "precision RFC3339" in cli, that query return date in 1970 year like '1970-01-18T20:31:51.774019Z' but correct time is '2018-11-20T20:31:51.774019Z'






    > precision RFC3339
    > select * from "lv_table" limit 10
    name: lv_table
    time Listing_id event_id event_type
    ---- ---------- -------- ----------
    1970-01-18T20:31:51.774019Z 105202696 4 "leads"
    1970-01-18T20:31:51.77402Z 105497566 66 "view"
    1970-01-18T20:31:51.774021Z 95532296 66 "view"
    1970-01-18T20:31:51.774021Z 98830991 1 "leads"
    1970-01-18T20:31:51.774022Z 105456186 66 "view"
    1970-01-18T20:31:51.774023Z 94326731 66 "view"
    1970-01-18T20:31:51.774025Z 104584666 66 "view"
    1970-01-18T20:31:51.774028Z 105603346 66 "view"
    1970-01-18T20:31:51.774035Z 99913981 66 "view"
    1970-01-18T20:31:51.774037Z 105430516 1 "leads"
    >





    What's the problem and how can I fix it?



    In aggregation query it gets worth ... and show time in 2016 but it should be in 2018-11-20 date



    1468800000000000 = Monday, July 18, 2016 12:00:00 AM






    select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
    >...
    name: lv_table
    tags: Listing_id=99965506
    time count_leads_event_id
    ---- --------------------
    1468800000000000 1

    name: lv_table
    tags: Listing_id=99965771
    time count_leads_event_id
    ---- --------------------
    1468800000000000 2

    name: lv_table
    tags: Listing_id=99966146
    time count_leads_event_id
    ---- --------------------
    1468800000000000 1

    name: lv_table
    tags: Listing_id=99966736
    time count_leads_event_id
    ---- --------------------
    1468800000000000 3
    ...





    If I don't use group by on time, time will be equal 0










    share|improve this question



























      2












      2








      2







      I'm a new influxdb user and my influxDB version is 1.7.1. I have problem with time in influx.



      I have a measurement called lv_table, Listing_id and event_type are tags and event_id is field






      select *  from "lv_table" limit 10 
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1542711774019000 105202696 4 "leads"
      1542711774020000 105497566 66 "view"
      1542711774021000 95532296 66 "view"
      1542711774021000 98830991 1 "leads"
      1542711774022000 105456186 66 "view"
      1542711774023000 94326731 66 "view"
      1542711774025000 104584666 66 "view"
      1542711774028000 105603346 66 "view"
      1542711774035000 99913981 66 "view"
      1542711774037000 105430516 3 "leads"





      but when I use "precision RFC3339" in cli, that query return date in 1970 year like '1970-01-18T20:31:51.774019Z' but correct time is '2018-11-20T20:31:51.774019Z'






      > precision RFC3339
      > select * from "lv_table" limit 10
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1970-01-18T20:31:51.774019Z 105202696 4 "leads"
      1970-01-18T20:31:51.77402Z 105497566 66 "view"
      1970-01-18T20:31:51.774021Z 95532296 66 "view"
      1970-01-18T20:31:51.774021Z 98830991 1 "leads"
      1970-01-18T20:31:51.774022Z 105456186 66 "view"
      1970-01-18T20:31:51.774023Z 94326731 66 "view"
      1970-01-18T20:31:51.774025Z 104584666 66 "view"
      1970-01-18T20:31:51.774028Z 105603346 66 "view"
      1970-01-18T20:31:51.774035Z 99913981 66 "view"
      1970-01-18T20:31:51.774037Z 105430516 1 "leads"
      >





      What's the problem and how can I fix it?



      In aggregation query it gets worth ... and show time in 2016 but it should be in 2018-11-20 date



      1468800000000000 = Monday, July 18, 2016 12:00:00 AM






      select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
      >...
      name: lv_table
      tags: Listing_id=99965506
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99965771
      time count_leads_event_id
      ---- --------------------
      1468800000000000 2

      name: lv_table
      tags: Listing_id=99966146
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99966736
      time count_leads_event_id
      ---- --------------------
      1468800000000000 3
      ...





      If I don't use group by on time, time will be equal 0










      share|improve this question















      I'm a new influxdb user and my influxDB version is 1.7.1. I have problem with time in influx.



      I have a measurement called lv_table, Listing_id and event_type are tags and event_id is field






      select *  from "lv_table" limit 10 
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1542711774019000 105202696 4 "leads"
      1542711774020000 105497566 66 "view"
      1542711774021000 95532296 66 "view"
      1542711774021000 98830991 1 "leads"
      1542711774022000 105456186 66 "view"
      1542711774023000 94326731 66 "view"
      1542711774025000 104584666 66 "view"
      1542711774028000 105603346 66 "view"
      1542711774035000 99913981 66 "view"
      1542711774037000 105430516 3 "leads"





      but when I use "precision RFC3339" in cli, that query return date in 1970 year like '1970-01-18T20:31:51.774019Z' but correct time is '2018-11-20T20:31:51.774019Z'






      > precision RFC3339
      > select * from "lv_table" limit 10
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1970-01-18T20:31:51.774019Z 105202696 4 "leads"
      1970-01-18T20:31:51.77402Z 105497566 66 "view"
      1970-01-18T20:31:51.774021Z 95532296 66 "view"
      1970-01-18T20:31:51.774021Z 98830991 1 "leads"
      1970-01-18T20:31:51.774022Z 105456186 66 "view"
      1970-01-18T20:31:51.774023Z 94326731 66 "view"
      1970-01-18T20:31:51.774025Z 104584666 66 "view"
      1970-01-18T20:31:51.774028Z 105603346 66 "view"
      1970-01-18T20:31:51.774035Z 99913981 66 "view"
      1970-01-18T20:31:51.774037Z 105430516 1 "leads"
      >





      What's the problem and how can I fix it?



      In aggregation query it gets worth ... and show time in 2016 but it should be in 2018-11-20 date



      1468800000000000 = Monday, July 18, 2016 12:00:00 AM






      select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
      >...
      name: lv_table
      tags: Listing_id=99965506
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99965771
      time count_leads_event_id
      ---- --------------------
      1468800000000000 2

      name: lv_table
      tags: Listing_id=99966146
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99966736
      time count_leads_event_id
      ---- --------------------
      1468800000000000 3
      ...





      If I don't use group by on time, time will be equal 0






      select *  from "lv_table" limit 10 
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1542711774019000 105202696 4 "leads"
      1542711774020000 105497566 66 "view"
      1542711774021000 95532296 66 "view"
      1542711774021000 98830991 1 "leads"
      1542711774022000 105456186 66 "view"
      1542711774023000 94326731 66 "view"
      1542711774025000 104584666 66 "view"
      1542711774028000 105603346 66 "view"
      1542711774035000 99913981 66 "view"
      1542711774037000 105430516 3 "leads"





      select *  from "lv_table" limit 10 
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1542711774019000 105202696 4 "leads"
      1542711774020000 105497566 66 "view"
      1542711774021000 95532296 66 "view"
      1542711774021000 98830991 1 "leads"
      1542711774022000 105456186 66 "view"
      1542711774023000 94326731 66 "view"
      1542711774025000 104584666 66 "view"
      1542711774028000 105603346 66 "view"
      1542711774035000 99913981 66 "view"
      1542711774037000 105430516 3 "leads"





      > precision RFC3339
      > select * from "lv_table" limit 10
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1970-01-18T20:31:51.774019Z 105202696 4 "leads"
      1970-01-18T20:31:51.77402Z 105497566 66 "view"
      1970-01-18T20:31:51.774021Z 95532296 66 "view"
      1970-01-18T20:31:51.774021Z 98830991 1 "leads"
      1970-01-18T20:31:51.774022Z 105456186 66 "view"
      1970-01-18T20:31:51.774023Z 94326731 66 "view"
      1970-01-18T20:31:51.774025Z 104584666 66 "view"
      1970-01-18T20:31:51.774028Z 105603346 66 "view"
      1970-01-18T20:31:51.774035Z 99913981 66 "view"
      1970-01-18T20:31:51.774037Z 105430516 1 "leads"
      >





      > precision RFC3339
      > select * from "lv_table" limit 10
      name: lv_table
      time Listing_id event_id event_type
      ---- ---------- -------- ----------
      1970-01-18T20:31:51.774019Z 105202696 4 "leads"
      1970-01-18T20:31:51.77402Z 105497566 66 "view"
      1970-01-18T20:31:51.774021Z 95532296 66 "view"
      1970-01-18T20:31:51.774021Z 98830991 1 "leads"
      1970-01-18T20:31:51.774022Z 105456186 66 "view"
      1970-01-18T20:31:51.774023Z 94326731 66 "view"
      1970-01-18T20:31:51.774025Z 104584666 66 "view"
      1970-01-18T20:31:51.774028Z 105603346 66 "view"
      1970-01-18T20:31:51.774035Z 99913981 66 "view"
      1970-01-18T20:31:51.774037Z 105430516 1 "leads"
      >





      select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
      >...
      name: lv_table
      tags: Listing_id=99965506
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99965771
      time count_leads_event_id
      ---- --------------------
      1468800000000000 2

      name: lv_table
      tags: Listing_id=99966146
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99966736
      time count_leads_event_id
      ---- --------------------
      1468800000000000 3
      ...





      select count(*) as count_leads  from "lv_table" where "event_type" = '"leads"' and time < 1542745800000000 group by Listing_id,time(1d)
      >...
      name: lv_table
      tags: Listing_id=99965506
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99965771
      time count_leads_event_id
      ---- --------------------
      1468800000000000 2

      name: lv_table
      tags: Listing_id=99966146
      time count_leads_event_id
      ---- --------------------
      1468800000000000 1

      name: lv_table
      tags: Listing_id=99966736
      time count_leads_event_id
      ---- --------------------
      1468800000000000 3
      ...






      time precision aggregation influxdb






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 21 '18 at 13:39

























      asked Nov 21 '18 at 13:20









      Zahra Safavifar

      133




      133
























          1 Answer
          1






          active

          oldest

          votes


















          0














          Influxdb stores timestamps internally as nanoseconds since Jan 1 1970, so your first datapoint is actually interpreted as:

          1542711774019000 ns -> 1542711 s -> Sun Jan 18 20:31:51 UTC 1970

          and this is what you see when use "precision RFC3339" in cli.



          Not sure how you got




          1468800000000000 = Monday, July 18, 2016 12:00:00 AM





          1468800000000000 ns -> 1468800 s -> Sun Jan 18 00:00:00 UTC 1970

          This is your first datapoint timestamp rounded to 1 day.



          You didn't describe how your put data into table. In Influx HTTP API you can specify precision of input timestamp data with an optional query parameter (see InfluxDB HTTP API reference).



          Precision setting in influx tells how to treat input timestamp data. Timestamp value on input is always integer (not rfc3339 string). And this integer is interpreted according to precision setting.




          precision=[ns,u,ms,s,m,h] Optional Sets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision (see Influx docs here)




          It also affects output format for query result. See examples below:



          ```



          > precision ns
          > insert demo value="precisionNS TS treated as nanoseconds" 1543220939000000000
          > precision s
          > insert demo value="precisionS TS treated as seconds" 1543220940
          > precision ms
          > insert demo value="precisionMS TS treated as ms" 1543220940123
          > precision rfc3339
          > select * from demo
          name: demo
          time value
          ---- -----
          2018-11-26T08:28:59Z precisionNS TS treated as nanoseconds
          2018-11-26T08:28:59.123456789Z precisionNS TS treated as nanoseconds
          2018-11-26T08:29:00Z precisionS TS treated as seconds
          2018-11-26T08:29:00.123Z precisionMS TS treated as ms
          >
          > precision s
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939 precisionNS TS treated as nanoseconds
          1543220939 precisionNS TS treated as nanoseconds
          1543220940 precisionS TS treated as seconds
          1543220940 precisionMS TS treated as ms
          >
          > precision ns
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939000000000 precisionNS TS treated as nanoseconds
          1543220939123456789 precisionNS TS treated as nanoseconds
          1543220940000000000 precisionS TS treated as seconds
          1543220940123000000 precisionMS TS treated as ms


          ```






          share|improve this answer























          • Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
            – Zahra Safavifar
            Nov 24 '18 at 6:31












          • I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
            – Zahra Safavifar
            Nov 24 '18 at 6:41













          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53412970%2finflux-aggregation-query-return-wrong-time%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          Influxdb stores timestamps internally as nanoseconds since Jan 1 1970, so your first datapoint is actually interpreted as:

          1542711774019000 ns -> 1542711 s -> Sun Jan 18 20:31:51 UTC 1970

          and this is what you see when use "precision RFC3339" in cli.



          Not sure how you got




          1468800000000000 = Monday, July 18, 2016 12:00:00 AM





          1468800000000000 ns -> 1468800 s -> Sun Jan 18 00:00:00 UTC 1970

          This is your first datapoint timestamp rounded to 1 day.



          You didn't describe how your put data into table. In Influx HTTP API you can specify precision of input timestamp data with an optional query parameter (see InfluxDB HTTP API reference).



          Precision setting in influx tells how to treat input timestamp data. Timestamp value on input is always integer (not rfc3339 string). And this integer is interpreted according to precision setting.




          precision=[ns,u,ms,s,m,h] Optional Sets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision (see Influx docs here)




          It also affects output format for query result. See examples below:



          ```



          > precision ns
          > insert demo value="precisionNS TS treated as nanoseconds" 1543220939000000000
          > precision s
          > insert demo value="precisionS TS treated as seconds" 1543220940
          > precision ms
          > insert demo value="precisionMS TS treated as ms" 1543220940123
          > precision rfc3339
          > select * from demo
          name: demo
          time value
          ---- -----
          2018-11-26T08:28:59Z precisionNS TS treated as nanoseconds
          2018-11-26T08:28:59.123456789Z precisionNS TS treated as nanoseconds
          2018-11-26T08:29:00Z precisionS TS treated as seconds
          2018-11-26T08:29:00.123Z precisionMS TS treated as ms
          >
          > precision s
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939 precisionNS TS treated as nanoseconds
          1543220939 precisionNS TS treated as nanoseconds
          1543220940 precisionS TS treated as seconds
          1543220940 precisionMS TS treated as ms
          >
          > precision ns
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939000000000 precisionNS TS treated as nanoseconds
          1543220939123456789 precisionNS TS treated as nanoseconds
          1543220940000000000 precisionS TS treated as seconds
          1543220940123000000 precisionMS TS treated as ms


          ```






          share|improve this answer























          • Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
            – Zahra Safavifar
            Nov 24 '18 at 6:31












          • I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
            – Zahra Safavifar
            Nov 24 '18 at 6:41


















          0














          Influxdb stores timestamps internally as nanoseconds since Jan 1 1970, so your first datapoint is actually interpreted as:

          1542711774019000 ns -> 1542711 s -> Sun Jan 18 20:31:51 UTC 1970

          and this is what you see when use "precision RFC3339" in cli.



          Not sure how you got




          1468800000000000 = Monday, July 18, 2016 12:00:00 AM





          1468800000000000 ns -> 1468800 s -> Sun Jan 18 00:00:00 UTC 1970

          This is your first datapoint timestamp rounded to 1 day.



          You didn't describe how your put data into table. In Influx HTTP API you can specify precision of input timestamp data with an optional query parameter (see InfluxDB HTTP API reference).



          Precision setting in influx tells how to treat input timestamp data. Timestamp value on input is always integer (not rfc3339 string). And this integer is interpreted according to precision setting.




          precision=[ns,u,ms,s,m,h] Optional Sets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision (see Influx docs here)




          It also affects output format for query result. See examples below:



          ```



          > precision ns
          > insert demo value="precisionNS TS treated as nanoseconds" 1543220939000000000
          > precision s
          > insert demo value="precisionS TS treated as seconds" 1543220940
          > precision ms
          > insert demo value="precisionMS TS treated as ms" 1543220940123
          > precision rfc3339
          > select * from demo
          name: demo
          time value
          ---- -----
          2018-11-26T08:28:59Z precisionNS TS treated as nanoseconds
          2018-11-26T08:28:59.123456789Z precisionNS TS treated as nanoseconds
          2018-11-26T08:29:00Z precisionS TS treated as seconds
          2018-11-26T08:29:00.123Z precisionMS TS treated as ms
          >
          > precision s
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939 precisionNS TS treated as nanoseconds
          1543220939 precisionNS TS treated as nanoseconds
          1543220940 precisionS TS treated as seconds
          1543220940 precisionMS TS treated as ms
          >
          > precision ns
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939000000000 precisionNS TS treated as nanoseconds
          1543220939123456789 precisionNS TS treated as nanoseconds
          1543220940000000000 precisionS TS treated as seconds
          1543220940123000000 precisionMS TS treated as ms


          ```






          share|improve this answer























          • Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
            – Zahra Safavifar
            Nov 24 '18 at 6:31












          • I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
            – Zahra Safavifar
            Nov 24 '18 at 6:41
















          0












          0








          0






          Influxdb stores timestamps internally as nanoseconds since Jan 1 1970, so your first datapoint is actually interpreted as:

          1542711774019000 ns -> 1542711 s -> Sun Jan 18 20:31:51 UTC 1970

          and this is what you see when use "precision RFC3339" in cli.



          Not sure how you got




          1468800000000000 = Monday, July 18, 2016 12:00:00 AM





          1468800000000000 ns -> 1468800 s -> Sun Jan 18 00:00:00 UTC 1970

          This is your first datapoint timestamp rounded to 1 day.



          You didn't describe how your put data into table. In Influx HTTP API you can specify precision of input timestamp data with an optional query parameter (see InfluxDB HTTP API reference).



          Precision setting in influx tells how to treat input timestamp data. Timestamp value on input is always integer (not rfc3339 string). And this integer is interpreted according to precision setting.




          precision=[ns,u,ms,s,m,h] Optional Sets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision (see Influx docs here)




          It also affects output format for query result. See examples below:



          ```



          > precision ns
          > insert demo value="precisionNS TS treated as nanoseconds" 1543220939000000000
          > precision s
          > insert demo value="precisionS TS treated as seconds" 1543220940
          > precision ms
          > insert demo value="precisionMS TS treated as ms" 1543220940123
          > precision rfc3339
          > select * from demo
          name: demo
          time value
          ---- -----
          2018-11-26T08:28:59Z precisionNS TS treated as nanoseconds
          2018-11-26T08:28:59.123456789Z precisionNS TS treated as nanoseconds
          2018-11-26T08:29:00Z precisionS TS treated as seconds
          2018-11-26T08:29:00.123Z precisionMS TS treated as ms
          >
          > precision s
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939 precisionNS TS treated as nanoseconds
          1543220939 precisionNS TS treated as nanoseconds
          1543220940 precisionS TS treated as seconds
          1543220940 precisionMS TS treated as ms
          >
          > precision ns
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939000000000 precisionNS TS treated as nanoseconds
          1543220939123456789 precisionNS TS treated as nanoseconds
          1543220940000000000 precisionS TS treated as seconds
          1543220940123000000 precisionMS TS treated as ms


          ```






          share|improve this answer














          Influxdb stores timestamps internally as nanoseconds since Jan 1 1970, so your first datapoint is actually interpreted as:

          1542711774019000 ns -> 1542711 s -> Sun Jan 18 20:31:51 UTC 1970

          and this is what you see when use "precision RFC3339" in cli.



          Not sure how you got




          1468800000000000 = Monday, July 18, 2016 12:00:00 AM





          1468800000000000 ns -> 1468800 s -> Sun Jan 18 00:00:00 UTC 1970

          This is your first datapoint timestamp rounded to 1 day.



          You didn't describe how your put data into table. In Influx HTTP API you can specify precision of input timestamp data with an optional query parameter (see InfluxDB HTTP API reference).



          Precision setting in influx tells how to treat input timestamp data. Timestamp value on input is always integer (not rfc3339 string). And this integer is interpreted according to precision setting.




          precision=[ns,u,ms,s,m,h] Optional Sets the precision for the supplied Unix time values. InfluxDB assumes that timestamps are in nanoseconds if you do not specify precision (see Influx docs here)




          It also affects output format for query result. See examples below:



          ```



          > precision ns
          > insert demo value="precisionNS TS treated as nanoseconds" 1543220939000000000
          > precision s
          > insert demo value="precisionS TS treated as seconds" 1543220940
          > precision ms
          > insert demo value="precisionMS TS treated as ms" 1543220940123
          > precision rfc3339
          > select * from demo
          name: demo
          time value
          ---- -----
          2018-11-26T08:28:59Z precisionNS TS treated as nanoseconds
          2018-11-26T08:28:59.123456789Z precisionNS TS treated as nanoseconds
          2018-11-26T08:29:00Z precisionS TS treated as seconds
          2018-11-26T08:29:00.123Z precisionMS TS treated as ms
          >
          > precision s
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939 precisionNS TS treated as nanoseconds
          1543220939 precisionNS TS treated as nanoseconds
          1543220940 precisionS TS treated as seconds
          1543220940 precisionMS TS treated as ms
          >
          > precision ns
          > select * from demo
          name: demo
          time value
          ---- -----
          1543220939000000000 precisionNS TS treated as nanoseconds
          1543220939123456789 precisionNS TS treated as nanoseconds
          1543220940000000000 precisionS TS treated as seconds
          1543220940123000000 precisionMS TS treated as ms


          ```







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 26 '18 at 9:25

























          answered Nov 22 '18 at 16:39









          Yuri Lachin

          73226




          73226












          • Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
            – Zahra Safavifar
            Nov 24 '18 at 6:31












          • I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
            – Zahra Safavifar
            Nov 24 '18 at 6:41




















          • Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
            – Zahra Safavifar
            Nov 24 '18 at 6:31












          • I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
            – Zahra Safavifar
            Nov 24 '18 at 6:41


















          Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
          – Zahra Safavifar
          Nov 24 '18 at 6:31






          Thank Yuri, but when I convert 1542711774019000 to human readable time in "epochconverter.com" site I get "GMT: Tuesday, November 20, 2018 11:02:54.019 AM" as a result that is correct time. you men that "precision RFC3339" first interpret "ns" to "s" ???
          – Zahra Safavifar
          Nov 24 '18 at 6:31














          I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
          – Zahra Safavifar
          Nov 24 '18 at 6:41






          I use NiFi to insert data in influx. I create query like lv_table,Listing_id=101510816,event_type="view" event_id="66" 1543041515116000 and "putinfluxdb" processor in NiFi insert this query to influx
          – Zahra Safavifar
          Nov 24 '18 at 6:41




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53412970%2finflux-aggregation-query-return-wrong-time%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python