I have InfluxDB records that look like this:
Some_Measurement:
---------------------
time field value
----- ------ -----
1630686612 myfieldA 123
1630686612 myfieldB 456
For some reason when I try to graph these in Grafana, or even to a select query like:
SELECT * FROM Some_Measurement WHERE "time" > now() - 60m
I get nothing back. It's almost as if it does not recognize the timestamps as timestamps. I have a feeling this might be because I'm writing these from my source as strings, but I have no idea what the correct data type should be. Could someone please help me out?
This is by default in the terminal query, but you can change this by the below command :
precision rfc3339
After applying the above command it gives the properly formatted time in the select commands
Related
I am trying to find the difference between two timestamps in Hive. But the date_time field is STRING, so I need to convert it to date_time format before finding the time difference.
This is the code I am using, but I get NULL.
SELECT UNIX_TIMESTAMP(TO_DATE("2016-12-30 10:39:46"),'HH:MM:SS') - UNIX_TIMESTAMP(TO_DATE("2016-12-30 10:39:31"),'HH:MM:SS');
I would need the difference to be 15 seconds.
Any suggestions would be great !!
Please try this:
select UNIX_TIMESTAMP('2016-12-30 10:39:46') - UNIX_TIMESTAMP('2016-12-30 10:39:31');
It should give time difference in seconds.
I have the following formula:
TIMESTAMPADD(SQL_TSI_SECOND, CAST(("Agent Performance Facts"."ACD After Call Work Outbound Time (Seconds)" + "Agent Performance Facts"."Inbound Talk Time (Seconds)" + "Agent Performance Facts"."Inbound Hold Time (Seconds)") AS INTEGER), TIMESTAMP '1999-01-01 00:00:00')
When report created I get time as the following example 1/1/1999 4:08:40 AM I want it to show like this only 4:08 how can I do that ?
From the Criteria, edit the column properties and under Data Format, set the format to HH:mm. You'll probably have to use a custom date format as this won't be in the list of defaults.
FILTER("source"."recordCount" USING "source"."snapshot_date" =
EVALUATE('TO_CHAR(%1, ''YYYYMMDD'')', TIMESTAMPADD(SQL_TSI_DAY, -7, EVALUATE('TO_DATE(%1, %2)', "source"."snapshot_date" , 'YYYYMMDD'))))
So i have this piece of code here. I know some will say "Just use the AGO function" But somehow it's causing problems because of it's connection with other tables so what I'm trying to achieve here is like a remake. The process goes this way:
The snapshot_date there is actually in varchar format and not date. So it's like "20131016" and I'm trying to change it to a date then subtract 7 days from it using the TIMESTAMPADD function and then finally returning it back to varchar to use it with FILTER.
This snippet somehow works when testing the FILTER using hardcoded values like "20131016" for example but when tested out with the code above all the row are blank. On paper, the process i assumed would happen goes lke this. "20131016" turns to a date with a format of 20131016 (yyyymmdd) and then less 7 days: 20131009 and then turned into char again "20131009" to be used in the filter.
But somehow that doesn't happen. I think the data format is not applying either to the string->date or the date->string conversion. which results to the values not getting a match at all.
Anyone have any idea what's wrong with my code?
By the way I've already tried to use CAST instead of EVALUATE or TO_TIMEDATE with the same result. Oh and this goes to the formula of the column in BMM.
Thanks
You might get some clues by looking at the SQL generated by the BI Server. I can't see any issues with your column expression, so I wouldn't limit your debugging to that alone.
A query returning nulls is often caused by incorrect levels being set (especially on logical table sources, but potentially on a measure column too). This will often result in some form of SELECT NULL FROM ... in the physical SQL.
Try this :
FILTER("source"."recordCount" USING "source"."snapshot_date" =
EVALUATE('TO_CHAR(%1, %2)', TIMESTAMPADD(SQL_TSI_DAY, -7, EVALUATE('TO_DATE(%1, %2)', TO_CHAR("source"."snapshot_date" , 'YYYYMMDD') , 'YYYYMMDD')) , 'YYYYMMDD'))
I'm not sure if this is a question or more of an exploration of a possible bug or a question about a better way to do handle this.
I have a rollup report that uses the
select column1id, column2date
from table1
where to_char(column2date,'yyyy-iw') = to_char(to_date('2012-12-31','yyyy-mm-dd'),'yyyy-iw')
The line: to_char(to_date('2012-12-31','yyyy-mm-dd'),'yyyy-iw') is converting to 2012-01, wrapping back to the beginning of the year.
Digging a bit further I find that the date 2012-12-31 is neither included in week: 2012-52 nor is it included in 2013-01, and 2012-53 doesn't return any data either... so I'm at a loss of what's going on here.
https://forums.oracle.com/forums/thread.jspa?threadID=995899
Ravi Kumar wrote: you need to use IYYY in format.
BluShadow wrote: ... When it calculates the YYYY and IW these are independant of each other so it won't reduce the YYYY output to [2013] just because you have included IW in the format mask. It looks at components of the mask and not the whole thing in combination.
select to_char(to_date('2012-12-31','yyyy-mm-dd'),'iyyy-iw') from dual;
returns 2013-01.
I think your WHERE clause should be:
where to_char(column2date,'iyyy-iw') = to_char(to_date('2012-12-31','yyyy-mm-dd'),'iyyy-iw')
I am calculating sum of all sales order (by multiplying quantity and price of a sales order - assume one sale order has only one item and using the sum function) in SQL query and I am spooling the output to a CSV file by using spool C:\scripts\output.csv.
The numeric output I get is truncated/rounded e.g. the SQL output 122393446 is made available in CSV as 122400000.
I tried to google and search on stackoverflow, but I could not get any hints about what can be done to prevent this.
Any clues?
Thanks
I think it is a xls issue.
Save as xls.
format column -> number with 2 decimals for example.
Initially I thought it might have something to do with the width of the number format which normally is 10 (NUMWIDTH) in sqlplus, but your result numeric width is 9, so that can not be the problem. Please check your query if you use a numeric type that doesn't have the required precission, and thus makes inexact calculations.