Issue selecting timespan values in KDB - kdb

I am facing an issue while selecting the following following timespan :
t:([] date:2#.z.d ; time: 10D21:28:47.425287000 10D12:18:23.287989000 )
date time
--------------------------------
2018.03.15 10D21:28:47.425287000
2018.03.15 10D12:18:23.287989000
when i run the following query, i am not getting the second record back
select from t where time within (12:00;13:00)
I am expecting the 2nd record from the table :
date time
-------------------------------
2018.03.15 10D12:18:23.287989000

Is the 10 in the time value 10D12:18:23.287989000 intentional ?
The reason behind the data not coming back is the time (type timespan ) is actually not the nano seconds since midnight ; as per the table it is 10 days plus nanos since midnight
To select the data only on the basis of time :
q)select from t where (`time$(`date$0)+time) within (12:00;13:00)
date time
-------------------------------
2018.03.15 10D12:18:23.287989000
Try adding the date and time from the table , you would see the date forwarded by 10 days
q)select date+time from t
date
-----------------------------
2018.03.25D21:28:47.425287000
2018.03.25D12:18:23.287989000
The timespan is basically nDhh:mm:ss.sssssssss , where n is relative to midnight. If its 0 then it's current day otherwise its +/- n days (depending on whether n is positive or negative).
try running the following , it will return you the difference between the 2 timestamps as a timespan with n=10.
q)2018.03.25D10:12:00.000000000 - 2018.03.15D10:00:00.000000000
10D00:12:00.000000000

Although you should fix your timestamps (there shouldn't be a 10D) if you're in a situation where you can't fix the upstream data but you believe the timestamps to actually be correct, then you can strip away the 10D as follows:
q)update mod[;`long$10D]time from t
date time
-------------------------------
2018.03.16 0D21:28:47.425287000
2018.03.16 0D12:18:23.287989000

Related

How to convert a timestamp into seconds (and fractions) in PostgreSQL

I'm trying to get some (application) performance data from a PostgreSQL database by looking at two dates in a record, subtracting them and getting the result as a number of seconds with fractions.
It seems I'm able to get a timestamp which includes hours, minutes, seconds, and milliseconds, or I can get just the seconds (and fractions) without e.g. the minutes or I can get a UNIX timestamp which is only seconds (without the milliseconds). Is there a convenient way to convert a timestamp to seconds+millis?
Example:
SELECT extract(SECOND FROM TIME '00:01:02.1234') as secs;
secs
--------
2.1234
I was hoping to get 62.1234 (that's 1 * 60 + 02.1234) as the return value for overall seconds, not just the "seconds component" from the time value.
Is there an existing function to do that, or do I have to EXTRACT each part, multiply, and add each component together?
Use EPOCH:
SELECT extract(EPOCH FROM TIME '00:01:02.1234') as secs; 62.1234

InfluxQL/Grafana: Get maximum per day

I want to get the maximum of a time series per day, so one data point each day at time 00:00:00. The maximum should be calculated over the range 00:00:00 until 23:59:59 for each day.
What i got so far:
SELECT max("temperature") FROM "Temperature" WHERE $timeFilter GROUP BY time(1d)
($timeFilter is used by Grafana for displaying only the selected time range)
With that query i get the output data points at the wrong time.
EDIT:
When i run
> precision rfc3339
> SELECT max("temperature") FROM "Temperature" WHERE time > now() - 7d GROUP BY time(1d) fill(null)
name: Temperature
time max
---- ---
2020-03-22T00:00:00Z 4.5
2020-03-23T00:00:00Z 9.687
2020-03-24T00:00:00Z 10.75
2020-03-25T00:00:00Z 8.5
2020-03-26T00:00:00Z 11.062
2020-03-27T00:00:00Z 10.25
...
in the CLI, the timestamps seem right.
But in Grafana the data points are placed at 02:00 each day.
Thanks!
Result from the InfluxDB is in the UTC. But Grafana interpolates timestamp to your browser timezone by default (so your browser/local environment reports your local timezone UTC+2). You can change this behavior in the dashboard configuration, for example you can keep timestamps in the UTC:
I think i found a solution myself:
Click '+' next to GROUP BY and select tz(), then enter the desired time zone.

postgres time conversion hh:mm:ss.us to hh:mm

Using PostgreSQL database for my attendance application.
I have a table with IN and out times (hh:mm:ss.us format).
When I subtract the times (OUT -IN) to calculate the working hours, results are not as expected due to precision.
If IN Time is "22:12:56.09"
& OUT TIme is "22:14:06.06" the difference considering only HH:mm should be 00:02 but it actually shows "00:01:09.97" which becomes "00:01" in excel using only HH:mm.
I am trying to do the time conversion from hh:mm:ss.us to hh:mm (time format) so that I can subtract the time and get the desired output.
I have done similar things in SQL Server but I did not find any function in PostgreSQL. Please advise.
First you need to truncate the seconds. Then subtract to get desired result
select
to_char(
(
to_char('22:14:06.06' :: time, 'HH24:MI'):: time -
to_char('22:12:56.09' :: time, 'HH24:MI'):: time
),
'HH24:MI'
)
Result: 00:02
General Solution:
select
to_char(
(
to_char(out, 'HH24:MI'):: time - to_char(in, 'HH24:MI'):: time
),
'HH24:MI'
)
Here the purpose of to_char() is to format result to hours:minutes and not to include seconds.
Postgres includes seconds in interval by default.
You can use the date_trunc function with timestamp.
It would work something like this:
select date_trunc('minute', out) - date_trunc('minute', in)
This would set a minute level precision on the timestamp and convert HH:mm:ss to HH:mm:00

inconsistency between month, day, second representation of interval data type

I understand why postgresql uses month,day and second fields to representate the sql interval datatype. A month is not always the same length and a day can have 23, 24 or 25 hours if a daylight savings time adjustment is involved. this is from postgresql documentation.
But I then do not understand why this is not consequently handled both for months and days. see the following query which calculates an exact interval where the number of seconds between two points in time is exactly calculatable:
select ('2017-01-01'::timestamp-'2016-01-01'::timestamp); -->366 days.
postgresql chooses to give a result in days. not in months and not in seconds.
But why is the result days and not seconds? it is NOT defined how long days are (they can be 23,24 or 25 hours long). so why does he not give output in seconds?
Then since the length of months is also not defined, why doesn't postgresql give an output of 12 month instead of 366 days?
He does not care that the length of days is not defined, but obviously he cares that the length of month is not defined.
Why this asymmetrie?
For further explanation, see this query:
select ('10 days'::interval-'24 hours'::interval); --> 10 days -24:00:00
you see that postgresql correctly refuses to answer with 9 days. He is pretty aware of the problem that days and hours cannot be interchanged. But then again why does the first query return days?
I can't answer your question, but I think I can point you in the right direction. I think the book SQL-99 Complete, Really is the most accessible source for understanding SQL intervals. It's available online: https://mariadb.com/kb/en/sql-99/08-temporal-values/.
SQL standards describe two kinds of intervals: year-month intervals and day-time intervals. It does this to prevent month parts and day parts from appearing in the same interval, because, as you already know, the number of days in a month is ambiguous. The number of days in the interval '3' month depends on which three months you're talking about.
I think this is the verbose, standard SQL way to write your first query.
select cast(timestamp '2017-01-01' - timestamp '2016-01-01' as interval day to hour) as new_column;
new_column
interval day to hour
--
366 days
I suspect that you'll find that SQL standards have rules for what a SQL dbms is supposed to do when things like interval day to hour are omitted. PostgreSQL might or might not follow those rules.
postgresql chooses to give a result in days. not in months and not in seconds.
Standard SQL prevents month parts and day parts from appearing in the same interval. Also, the range of valid seconds is from 0 to 59.
select interval '59' second;
interval
interval second
--
00:00:59
select interval '60' second;
interval
interval second
--
00:01:00

Q (KDB) selecting today's date within date range

I am trying to set up an dynamic threshold by different user, but only return result from today's date. I was able to return all the records from past 30 days, but I am having trouble only outputting today's date based on the calculation from past 30 days.. I am new to q language and really having a trouble with this simple statement :( (have tried and/or statement but not executing..) Thank you for all the help in advance!
select user, date, real*110 from table where date >= .z.D - 30, real> (3*(dev;real) fby user)+((avg;real) fby user)
Are you saying that you want to determine if any of todays "real" values are greater than 3 sigma based on the past 30 days? If so (without knowing much about your table structure) I'm guessing you could use something like this:
q)t:t,update user:`user2,real+(.0,39#10.0) from t:([] date:.z.D-til 40;user:`user1;real:20.1,10.0+39?.1 .0 -.1);
q)sigma:{avg[y]+x*dev y};
q)select from t where date>=.z.D-30, ({(.z.D=x`date)&x[`real]>sigma[3]exec real from x where date<>.z.D};([]date;real)) fby user
date user real
---------------------
2016.03.21 user1 20.1