I want to filter SignIn-Logs with Kusto whose timestamps are only between 6pm and 6am.
Something like that
SignInLogs
| where TimeGenerated between(dateStart .. dateEnd)
All examples I have found are always based on a full timestamp with exact date, like (2014-05-25T08:20:03.123456Z). But I am only interested in the time.
Any idea how to solve this?
Kusto: How to filter Logs in a certian time period?
between operator - Filters a record set for data that falls within an inclusive range of values.
between is used to allow a certain range, but you can also use !between to exclude a time range.
Here Iam excluding from 6 am to 6 pm , so it gives the left over time range i.e.. from 6pm to 6 am
Try the below query
SignInLogs
| where TimeGenerated > ago(1d)
| extend hour = datetime_part("hour", TimeGenerated)
| where hour !between (6 .. 18)
Related
I have a dataset where certain operations occur during the overnight hours which I'd like to attribute to the day before.
For example, anything happening between 2/23 8pm and 2/24 6am should be included in 2/23's metrics rather than 2/24. Anything from 6:01 am to 7:59pm should be counted in 2/24's metrics.
I've seen a few posts about decrementing time by 6 hours but that doesn't work in this case.
Is there a way to use an If function to specify that midnight-6am should be counted as date-1 rather than date without affecting the metrics for the 6am - 7:59pm hours?
Thanks in advance! Also, a SQL newbie here so apologies if I have lots of followup questions.
You can use date_add with -6 hours and then optionally cast the timestamp as a date.
create table t (dcol datetime);
insert into t values
('2022-02-25 06:01:00'),
('2022-02-25 06:00:00'),
('2022-02-25 05:59:00');
SELECT CAST(DATE_ADD(dcol, INTERVAL -6 HOUR)AS DATE) FROM t;
| CAST(DATE_ADD(dcol, INTERVAL -6 HOUR)AS DATE) |
| :-------------------------------------------- |
| 2022-02-25 |
| 2022-02-25 |
| 2022-02-24 |
db<>fiddle here
As said in the comments, your requirement is the occurrences in a 6 AM to 6 AM day instead of a 12-12 day. You can achieve this by decreasing the time by 6 hours as shown in #Kendle’s answer. Another way to do it is to use an IF condition as shown below. Here, the date is decremented if the time is before 6 AM on each day and the new date is put in a new column.
Query:
SELECT
IF
(TIME(eventTime) <= "06:00:00",
DATE_ADD(DATE(eventTime), INTERVAL -1 DAY),
DATE(eventTime)) AS newEventTime
FROM
`project.dataset.table`
ORDER BY
eventTime;
Output from sample data:
As seen in the output, timestamps before 6 AM are considered for the previous day while the ones after are considered in the current day.
I'm breaking my head trying to create a query for the following situation: I'm using an oracle database, I have a job that always runs at 00 o'clock, so I will fetch the beginning of a user's recess, in the example below we see how are the dates.
DATE_RECESS | USER_ID
---------------------------
22/09/21 | 1
21/09/21 | 1
20/09/21 | 1
19/09/21 | 1
18/09/21 | 1
I will need to notify him missing 10 days to the beginning of the recess, this notification will be sent only 1 time ...
So, looking at these dates with example, I should send 1 single notification on 08/09/21, I should not notify on the other days, only on the first day.
I can't send notification for every day, I should have some return just missing 10 days to start. Summarizing there's my doubt:
How to create a query, (which will be executed by a job that will run every day), and that does not bring result every day? Only when the first date is found?
For me to know what dates are missing 10 days I will take as base my current date, today + 10 days... if I find any date in this period then there I have a recess, but the return of the query should only bring something if it is date is the day 18/09/21, because there is beginning of the recess ... if today + 10 fall on the 19th I will bring nothing, because there will be the second day ...
First off I apologize I do not even know where to start and haven't been able to find anything specific to this particular question.
I have a table with datetimes (start and end) and i need to find a way to get minutes/hours between those days. It could either be a sum of the time on weekdays or a some kind of pivot on each day and grouping by the ID number. I had thought to assign a value to the number of days however the times are random and do not start/end at midnight so I am at a loss as how to approach this.
Here are some examples of the date/time format if that helps.
startdate 2018-12-14 10:53:01
enddate 2018-12-27 11:50:00
Any helps or hints would be greatly appreciated!
Edit
forgot to include I am working in SQL Server (SSMS)
Editing For Additional Clarification
Here is a sample date range with an ID number, I wanted to keep it simple.
|ID number| start time |end time
|1 |12/14/2018 10:53|12/17/2018 12:00
here is what I'm trying to achieve (the separation of each date range/ID #)
ID number| start time |end time |mins|
1 | 12/14/2018 10:53|12/14/2018 23:59|786 |
1 | 12/15/2018 0:00 |12/15/2018 23:59|1439|
1 | 12/16/2018 0:00 |12/16/2018 23:59|1439|
1 | 12/17/2018 0:00 |12/17/2018 12:00|960 |
The MINUTE parameter of the DATEDIFF function can be used to determine the difference in minutes between two datetime columns. As below, the second parameter is the start date and the third parameter is the end date, with the result being the amount of time in the specified interval (days, minutes, etc.) from the start to the end date. If you need to find the number of hours between these two columns the HOUR parameter can be used for this. Grouping can be performed as well, as in the second example.
DATEDIFF:
SELECT DATEDIFF(MINUTE, StartDateColumn, EndDateColumn)
DATEDIFF with Grouping and Aggregation:
SELECT ColumnA, SUM(DATEDIFF(MINUTE, StartDateColumn, EndDateColumn)) as DifferenceInMinutes
FROM YourSchema.YourTable
GROUP BY ColumnA
In one of my SQL queries, I am using
[... and z.READ_TIMESTAMP > TIMESTAMP_TO_EPOCH(TRUNC(SYSDATE-3)]
If I want the date to be exactly 5/31/2017, will I use 'SYSDATE' (date-n) function or some other expression? or how can a modify my query for 5/31/2017
If you want the date to be exactly 5/31/2017 then use TO_DATE() or TO_TIMESTAMP() depending on which data type you need (date or timestamp). As you are using SYSDATE already the the date data type should work.
-- e.g.
select
to_date('5/31/2017','mm/dd/yyyy')
, to_timestamp('5/31/2017','mm/dd/yyyy')
from dual
...
and z.READ_TIMESTAMP > TIMESTAMP_TO_EPOCH(to_date('5/31/2017','mm/dd/yyyy'))
HOWEVER
I suspect you may want more than just a way to establish a fixed date. For example are you asking for "how do I get that last day of the previous month?" which perhaps can be satisfied by using >= and the first day of current month like this:
...
and z.READ_TIMESTAMP >= TIMESTAMP_TO_EPOCH(trunc(sysdate,'MM'))
or if it really is the last day of the previous month can be achieved with a combination of LAST_DAY() and ADD_MONTHS()
and z.READ_TIMESTAMP >
TIMESTAMP_TO_EPOCH( last_day(add_months(trunc(sysdate,'MM'),-1)) )
Without knowing a great deal more about the nature of your data and query purpose please do note that each date you use when "truncated" also has the time set to 00:00:000 - so IF you data contains time within a day other than 00:00:00 then these 2 queries might NOT produce the same result
.... datetimecolumn > to_date('05/31/2017','mm/dd/yyyy') -- "a"
.... datetimecolumn >= to_date('06/01/2017','mm/dd/yyyy') -- "b"
For example "a" the entire 24 hour duration of 05/31/2017 would be included in the results, but for example "b" that same 24 hour duration would be excluded from results. In my experience the last day of any month isn't really the best method for locating date/time based data, instead usually it is the first day of the next month that produces the correct result.
In my application, I have a database storing a calendar of events:
id | name | date
----+--------------------+--------------------
1 | Birthday Party | 2013-04-27 16:30:00
2 | Dinner Reservation | 2013-03-20 17:00:00
3 | Sunday Brunch | 2013-03-31 11:15:00
When viewing events in the application, users should be able to configure how far in advance from the present moment they wish to view events, stored as a value in the database:
username | datediff
----------+------------------------------------------
user123 | 2 days in advance
goodguy | 93 days in advance
spudly | 365 days in advance
aaaaaa | 17 days, 3 hours, 30 seconds in advance
My question is: what is the best (i.e., most SQL-idiomatic) way to store such a date differential? I could store the time difference as a number in milliseconds, but is there some built-in SQL datatype that is suitable for date differentials, rather than just particular points in time? Is something like DATETIME or TIMESTAMP appropriate for this task?
It must be a relative difference -- for example, for "2 days in advance" I'm not interested in storing a particular date two days in the future, because I'd like the user to see events for the next two days every time he looks at the application.
I'm using Microsoft SQL Server 2008, if it makes any difference.
(This may be a duplicate, but all my search attempts have turned up results about datediff -- which is used to calculate time differences -- but nothing about how best to store time differences.)
Standard SQL has a specific data type for date and time durations: interval. SQL Server doesn't support the interval data type.
DateDiff() returns a signed integer. If you need to store the SQL Server equivalent to a SQL interval, you'll need to store an integer. The integer is a count of the number of datepart boundaries, so you also need to store what kind of datepart boundary the integer refers to. Without the datepart, the signed integer 3 could just as easily mean 3 years or 3 seconds.
As a practical matter, I think I'd rather calculate a timestamp for the reminder, and store that instead of the integer and datepart that define an interval. A timestamp can be indexed and queried much more simply than the integer and datepart. And without the need to support recurring events, I don't see a compelling reason to build a solution more complicated than that.