i have a lot of data that has at start time and a finnish time. These are formated i datetime format.
i want to sum the time that occurs in an timeinterval
if specify the time interval 08-11
i only want to get the time between these to even if the evvent progresses from 06 to 12
If you are using SQL Server you could do it like that:
SELECT SUM(DATEDIFF(HOUR,StartTimeColumn,EndTimeColumn)) AS ElapsedHoursTotal,
SUM(DATEDIFF(MINUTE,StartTimeColumn,EndTimeColumn)) AS ElapsedMinutesTotal,
SUM(DATEDIFF(SECOND,StartTimeColumn,EndTimeColumn)) AS ElapsedSecondsTotal,
FROM dbo.YourTable
You will have to find the perfekt interval (First Parameter of DATEDIFF Function) for your requirements... Hours, Minutes, Seconds, Nanoseconds,...
Im using mssql 2012
the problem is that i can get the full elapsed time from start to finnish but I only want the part that matches my search
if the pattern i match for is 8-11
thing one 08-12 should produce 3 hours
thing two 10-11 should produce 1 hour
thing tre 9.30- 14 shoud produce 1.5 hour
Related
I have a grafana chart showing the data of the last 24 hours
But the data does not fit the time axis. There is missing 2 hours in the beginning of the 24 hour period. And the last value at 21:27:57 is 66.74 but at this time it was 73.50.
The time axis seems to be shifted by 2 hours. The data at time x shows the data of time x-2h.
The timestamp (datetime) in the SQL database is correct.
EDIT:
Changing the timezone doesn't help much. Using UTC (which is wrong for me) the most recent time on the time axis is about 20:40 (wrong)
Using UTC+2 (which fits my timezone) the most recent time is about 22:40, the correct local time when taking the screenshot.
The data is not affected and there is still 2 hours missing in the 24 hour period. And still the most recent value in the chart shows the value of 2 hours ago.
I don't really understand why, but I figured out that there is a UNIX_TIMESTAMP() needed:
SELECT
UNIX_TIMESTAMP(timestamp) AS "time",
humidity
FROM Sensor_BME280_01
WHERE
$__timeFilter(timestamp)
ORDER BY timestamp
instead of
SELECT
timestamp AS "time",
humidity
FROM Sensor_BME280_01
WHERE
$__timeFilter(timestamp)
ORDER BY timestamp
The value timestamp is of type DATETIME in a MariaDB.
I have a dataset which shows a datetimestamp for both the start and end of an agent status and I am trying to capture the duration within that hour interval of that status by using a simple datediff function in SQL Server 2012.
This works perfectly as long as the status start and end time are within the same hour. However, in cases where the status starts at 8:37 and finishes 10:15, I am having a hard time inserting an hour interval to perform the datediff function.
In the scenario above, I would like the data to show 23 minutes in the 8 am interval, 60 minutes in the 9 am interval, and 15 minutes in the 10 am interval.
I would like to check if the processed date is today.
xsl:if test="ProcessedDate = 'Today'" won't work since the value of processed date is a timestamp more like 2016-06-07T09:06:54.827z
How can I mathematically convert it to check the processed date to see if it's in the past 24 hrs.
Perhaps within a ().
I have a table described here: http://sqlfiddle.com/#!3/f8852/3
The date_time field for when the time is 00:00 is wrong. For example:
5/24/2013 00:00
This should really be:
5/23/2013 24:00
So hour 00:00 corresponds to the last hour of the previous day (I didn't create this table but have to work with it). Is there way quick way when I do a select I can replace all dates with 00:00 as the time with 24:00 the previous day? I can do it easily in python in a for loop but not quite sure how to structure it in sql. Appreciate the help.
All datetimes are instants in time, not spans of a finite length, and they can exist in only one day. The instant that represents Midnight is by definition, in the next day, the day in which it is the start of the day, i.e., a day is closed on its beginning and open at its end, or, to phrase it again, valid allowable time values within a single calendar date vary from 00:00:00.00000, to 23:59:59.9999.
This would be analogous to asking that the minute value within an hour be allowed to vary from 1 to 60, instead of from 0 to 59, and that the value of 60 was the last minute of the previous hour.
What you are talking about is only a display issue. Even if you could enter a date as 1 Jan 2013 24:00, (24:00:00 is not a legal time of day) it would be entered as a datetime at the start of the date 2 Jan, not at the end of 1 Jan.
One thing that illustrates this, is to notice that, because of rounding (SQL can only resolve datetimes to within about 300 milleseconds), if you create a datetime that is only a few milleseconds before midnight, it will round up to midnight and move to the next day, as can be seen by running the following in enterprise manager...
Select cast ('1 Jan 2013 23:59:59.999' as datetime)
SQL server stoers all datetimes as two integers, one that represents the number days since 1 Jan 1900, and the other the number of ticks (1 tick is 1/300th of a second, about 3.33 ms), since midnight. If it has been zero time interval since Midnight, it is stll the same day, not the previous day.
If you have been inserting data assuming that midnight 00:00:00 means the end of the day, you need to fix that.
If you need to correct your existing data, you need to add one day to every date in your database that has midnight as it's time component, (i.e., has a zero time component).
Update tbale set
date_time = dateAdd(day, 1, date_time)
Where date_time = dateadd(day, datediff(day, 0, date_time), 0)
I am writing a little query in SQL and am butting heads with an issue that it seems like someone must have run into before. I am trying to find the number of months between two dates. I am using an expression like ...
DATEDIFF(m,{firstdate},{seconddate})
However I notice that this function is tallying the times the date crosses the monthly threshold. In example...
DATEDIFF(m,3/31/2011,4/1/2011) will yield 1
DATEDIFF(m,4/1/2011,4/30/2011) will yield 0
DATEDIFF(m,3/1/2011,4/30/2011) will yield 1
Does anyone know how to find the months between two dates more-so based upon time passed then times passed the monthly threshold?
If you want to find some notional number of months, why not find the difference in days, then divide by 30 (cast to FLOAT as required). Or 30.5-ish perhaps - depends on how you want to handle the variable month length throughout the year. But perhaps that's not a factor in your particular case.
The following statements have the same startdate and the same endate. Those dates are adjacent and differ in time by .0000001 second. The difference between the startdate and endate in each statement crosses one calendar or time boundary of its datepart. Each statement returns 1. ...
SELECT DATEDIFF(month, '2005-12-31 23:59:59.9999999'
, '2006-01-01 00:00:00.0000000'); ....
(from DATEDIFF, section datepart Boundaries ). If you are not satisfied by it, you probably need to use days as unit as proposed by martin clayton
DATEDIFF(m,{firstdate},ISNULL({seconddate},GETDATE())) - CASE
WHEN DATEPART(d,{firstdate}) >= DATEPART(d,ISNULL({seconddate},GETDATE()))
THEN 1
ELSE 0
DATEDIFF is like this by design. When evaluating a particular time measurement (like months, or days, etc.), it considers only that measurement and higher values -- ignoring smaller ones. You'll run into this behavior with any time measurement. For example, if you used DATEDIFF to calculate days, and had one date a few seconds before midnight, and another date a few seconds after midnight, you'd get a "1" day difference, even though the two dates were only a few seconds apart.
DATEDIFF is meant to give a rough answer to questions, like this:
Question: how many years old are you?
Answer: some integer. You don't say "I'm 59 years, 4 months, 17 days, 5 hours, 35 minutes and 27 seconds old". You just say "I'm 59 years old". That's DATEDIFF's approach too.
If you want an answer that's tailored to some contextual meaning (like your son who says "I'm not 8! I'm 8 and 3-quarters!, or I'm almost 9!), then you should look at the next-smallest measurement and approximate with it. So if it's months you're after, then do a DATEDIFF on days or hours instead, and try to approximate months however it seems most relevant to your situation (maybe you want answers like 1-1/2 months, or 1.2 months, etc.) using CASE / IF-THEN kinds of logic.