I am using SQL Server and just identify one problem in my case.
I have used the DATEDIFF function as:
select datediff(dd,'1935-12-07','2010-03-02')/365.00 ---> 74.28
select datediff(dd,'1935-12-07','2010-03-02')/365 ---> 74
select datediff(yy,'1935-12-07','2010-03-02') ---> 75
If you can observe that If I try DATEDIFF with 'dd' then I get the difference as 74/74.28.
But If I use it with 'yy' I get the diference as 75.
Why this is so? Means Why the difference came as 75 as it nearly approximate to 74.
I need this both function in different cases. But as it is behaving differently I am facing a lot of problems.
Suggest me some solution to this.
Thanks.
First case = You're implicitly casting to a float, shows the correct result
Second case = You're implictly casting to an int, which rounds down as part of the conversion (Floor value)
Third case = You're not casting anything at all, and DATEDIFF() returns a signed int, which rounds up (Ceiling value)
Solution: Do whatever you want, but keep it consistent throughout your code.
The datediff function checks for the difference of the date part you have specified, so it is correct in saying the difference in the year part of the two dates is 75.
Or to word it as the folks at microsoft do, it counts the number of boundaries crossed of that datepart. There are 75 year-boundaries crossed between the two dates in your example.
Have a look at this msdn page, it explains how it is supposed to work.
Related
I am working on a time system that require manual input of the coming and going times. (not my system) I am building a dashboard for this system that will show average time on site and more. Because it requires a manually entered coming and going time, mistakes can happen. If someone checks in at 18:00hours but forgets to clock out, the system automatically leaves the clock out time at 0:00:00 hours.
When calculating my averages, if the above occurs, then it calculates the average time spent on site and adds in a -18:00 hours. This obviously breaks the whole calculation. Is there a way to have the query ignore any negatives to avoid this?
SELECT id, TIMEDIFF(`booking_time_out`, `booking_time`) AS 'Time_Spent'
FROM `table_name`
The negative result criteria is a result of the 0:00:00 booking out time so append the exclusion of that row in the where criteria like:
where booking_time_out != '0:00:00'
You seem to want a case expression:
select id,
case when timediff(`booking_time_out`, `booking_time`) < 0
then 0
else timediff(`booking_time_out`, `booking_time`)
end as time_spent
from tablename
Side note: do not surround identifiers with single quotes (as in as 'Time_spent'). In standard SQL, single quotes stand for literal strings. On the other hand, you usually do not need to quote an identifier (unless its name is really badly chosen) - and if you need to, the quoting character of MySQL is backticks.
I know that Gregorian calendar started on Oct 15th 1582, and during the transition from Julian calendar, 10 days had been dropped.
When I'm doing this query:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d')
I'm getting this result:
1582-10-15 (the 10 days difference).
But when I'm trying to match between such dates I'm getting the original date (Oct 5th and not 15th).
For example:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d') = STR_TO_DATE('1582-10-15', '%Y-%m-%d')
I'm getting a false response, although you would have expected to get a true since Oct 5th actually count as Oct 15th, as we saw in the first example.
Anyone can explain what's going on here?
On documentation it is stated that, TO_DAYS and FROM_DAYS functions must be called cautiously because of the transformation you noticed. Additionally, when I inspect the source codes of MySQL, I realized that STR_TO_DATE uses similar methodology with these functions. As I understand, cutover dates are completely unsafe to store or apply operations. Documentation says; "Dates during a cutover are nonexistent.", too.
Also for the inconsistency between different servers I may have an explanation. I have 2 different machines which have MySQL installed in Istanbul, Turkey and Frankfurt, Germany. They have same setup excluding localisation settings. First one shows 1, the other one shows 11 for the date substraction query. It means (in my humble opinion) there is unexplained sections about calendar cutover & localisation on official documentation.
Please see the following results:
SELECT STR_TO_DATE('1582-10-05', '%Y-%m-%d');
# Result #1: 1582-10-15
SELECT DATE_FORMAT(STR_TO_DATE('1582-10-05', '%Y-%m-%d'), '%Y-%m-%d');
# Result #2: 1582-10-05
SELECT DATE_FORMAT(STR_TO_DATE('1582-10-15', '%Y-%m-%d'), '%Y-%m-%d');
# Result #3: 1582-10-15
SQL fiddle demo.
These indicate the problem lies in the way the 1582-10-05 date is displayed rather than how it is stored. Result #2 shows that if the DATE_FORMAT function is used instead to explicitly convert the date into the same string format then the input date is displayed. This also explains why the comparison query in the question returns false: Behind the scenes, the two stored dates are different.
As you've discovered, this quirk occurs for all dates between 1582-10-05 and 1582-10-14 inclusive, i.e. the range of dates that don't really exist: The implicit conversion to text for all of these gives a date 10 days after. So if for some reason there is a need to display dates in this range (perhaps questionable), a simple workaround is to always use the DATE_FORMAT function.
I am struggling making sense of the TIMESTAMPDIFF() function using MYsql
here is an example:
SELECT TIMESTAMPDIFF(minute,start_time,end_time) AS Duration
FROM exam_answers
LIMIT 200;
Can someone explain to me what this is doing and what the purpose of me using it is? is their easier code? is this commonly used in business settings?
Thanks.
All this is doing is running a calculation on two fields in your data. So the function is returning the difference between the second and third parameters in the units defined by the first parameter.
TIMESTAMPDIFF(DAY, '2011-12-10', '2011-12-20')
will return 10. Because there are 10 days between Dec 10th and Dec 20th. That value is retrieved as Duration (just an alias).
Why is
TIMESTAMPDIFF(MONTH, '2015-12-25', '2016-02-24')
giving me 1? I would expect 2016-01-25 to be 1.
My guess is that it is actually returning something like 1.999 months and it is being simply rounded down.
How can I work around this? Or is there another function to use.
I tried PERIOD_DIFF but it does not take into account days
PERIOD_DIFF(DATE_FORMAT('2016-02-24','%Y%m'),DATE_FORMAT('2015-12-25','%Y%m'))
According to the documentation, the unit for the result is an integer, in your case it will return the whole number of months between the two dates, which is one (as the second month is not yet completed).
I am trying to get a total number of days hired using the DateDiff function is access.
I currently use:
=DateDiff("d",[hired_from],[hired_to])
To get the difference between two dates, however if the two dates selected are the same it will produce an output of 0, I would like it to produce an output of 1 when the two dates selected are the same, thanks.
It doesn't make much sense as the difference between two identical values always will be zero.
So you probably mean:
=DateDiff("d",DateAdd("d",-1,[hired_from]),[hired_to])
or just add one to the count:
=DateDiff("d",[hired_from],[hired_to])+1
I ended up making this work by using an if statement as shown:
==IIf(DateDiff("d",[hired_from],[hired_to])=0,1,DateDiff("d",[hired_from],[hired_to]))
to get the difference of two dates (which is only a format for an integer value), you have only to subtract the two dates and make sure that the result format is an integer.
Variable = [hired_to]-[hired_from]