This is a pretty simple homework problem that I've been stuck on for a while. Can someone show me how to go about solving this?
A baby is born on March 1 2012 12:00:00. How old will he be in minutes on July 4th 2013 13:30:00?
Use this query
SELECT TIMESTAMPDIFF(MINUTE, '2012-03-01', '2013-07-04')
Use DATEDIFF() to count the difference in days, than multiply it by 24 * 60 * 60 (number of seconds in a day)..
Related
I have a monthly offering that gives customers 30 minutes of use every month and I need to tally up their usage and group it by month, but not sure the best way to handle that since the start date could be any day of the month.
Should I prorate? Convert into full months or count the days?
Is there an ideal way to tally this? Let's say each month they get 30 minutes of use time, so I want to tally how many minutes were used that "month."
Say there is a minutes used table and the start date for the subscription is 2019-06-13 00:00:00
minutes_used_table:
Userid MinutesUsed Date
1 5 2019-06-19
1 6 2019-06-23
1 8 2019-06-28
1 15 2019-07-05
1 3 2019-07-12
1 8 2019-07-19
1 5 2019-08-14
1 3 2019-08-22
1 1 2019-08-26
1 2 2019-09-13
Or, should I prorate it and instead of tracking in 30 day increments, if they start on the 13th of June, should I just count the days from the start date to the end of the month, whatever day that is and then the days from the first of the month until the start date?
Wondering what makes the most sense and how to carry it out?
Use
GROUP BY DATEDIFF(`Date`, #starting_date) DIV #period_length
In your particular case it will be
GROUP BY DATEDIFF(`Date`, '2019-06-13 00:00:00') DIV 30
From coding point of view it's not a big deal to find first date for user, subtract it from dates and count number of 30-days periods.
But this will be very hard to support in future and this solution will have a number of corner cases: for example someone first start to use product at 20 January, after month of usage have been idle for a while and came back in April, 5. What will be right start date for that case?
So I suggest to use calendar months. And may be reduce limit on first month accordingly to the number of days left or give full trial period even on first month as user has ability to spend 30 minutes.
I'm trying to perform some time calculations (timestampadd, timestampdiff) on a query but I'm stuck with an unexpected behavior.
I executed in mysql this query:
select timestampdiff(MONTH, timestampadd(MONTH, 1, '2017-01-30'),'2017-01-30')
Using logic is adding to 2017-01-30 one month, then it requests the difference in months between this date and again 2017-01-30.
I'm expecting the result to be trivial and equal to 1 but instead the previous query evaluates to 0.
This screws my calculations.
Why is that?
This is straight forward,
you are adding 1 month in january 30 which will be feb 28 as in 2017
now the difference between jan30 and feb28 is only 29 days which is less than a month value. ( 30 days )
Therefore its 0
for accuracy, you need to handle february with care .
Specs: I'm using MySQL 5.6 with SQLWorkbench, SequelPro on OSX Yosemite
Query background: I'm trying to correct a set of TIMESTAMPDIFF durations for weekends and bank holidays. I have 2 stored procedures which are giving me the number of Saturdays, Sundays and Bank Holidays between two dates - these are working fine. To get the corrected TIMESTAMPDIFF, I therefore multiply the number of Saturdays, Sundays and holidays by 24 to get the number of hours to be subtracted, then subtract that number from the TIMESTAMPDIFF.
Example: As an example, if timestamp A is 14:00 on Friday and timestamp B is 14:01 on Tuesday, the raw TIMESTAMPDIFF is 96:01:00. Assuming Monday is holiday and the weekend is 48:00:00, I want to subtract 72:00:00 from 96:01:00, to get the 'business day difference' of 24:01:00.
The problem: When I do something like "96:01:00" - "72:00:00" as date_sub_test, I get 24. I have lost all formatting, including the 01 minute. Duration are not DATETIME, as they don't correspond to calendar dates, so I can't use DATE_ADD / DATE_SUB.
The question: How should I subtract time from a duration, retaining formatting and relevant base 60 system eg 60 minutes in an hour, not 100?
Thanks in advance!
As Jaydee mentions in a comment:
Have you tried the TIMEDIFF function? https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_timediff
TIMEDIFF was what I was looking for. I also added in ABS() to make negative time differences positive, and MAKETIME() to create a time from an integer.
Use SEC_TO_TIME and TIME_TO_SEC like
SELECT SEC_TO_TIME(TIME_TO_SEC('96:01:00')-TIME_TO_SEC('72:00:00'))
you can use ABS like this
SELECT SEC_TO_TIME(ABS(TIME_TO_SEC('96:01:00')-TIME_TO_SEC('172:00:00')))
Hello
I need to list the shifts that contains this period between 22:00 and 05:00:
SELECT *
FROM shift
WHERE hourstart>='22:00:00' AND hourend<='05:00:00'
How can i do it?
Thank you
Hours start <= 22 and hoursend >=5 or hoursend >=22 or hours start <=5 or hours start >=22
I tried to do the following query to subtract one day from the given date:
DATE(FROM_UNIXTIME(UNIX_TIMESTAMP('2013-04-01') - 86400))
which returns me 2013-03-30, but it should return 2013-03-31.
If i try to subtract one day of 2013-04-02, i get 2013-04-01 correctly returned.
Is this a date bug in mysql?
It's not a bug - what you have found is the missing hour in daylight saving time: a thing unixtime and your calculation is unaware of since you calculate with seconds and not days.
This is exactly why DBMS have special DATETIME datatypes - to handle all the specialities in timezones, leap years, leap seconds, daylight savings and calendars.
Let the database do the work for you - here is an easier and better way to get what you want:
SELECT DATE('2013-04-01') - INTERVAL 1 DAY
Your code makes the assumption that all days have 24 hours. Yesterday, 31st March, had 23 hours in most European countries. To subtract one day you need something like this:
SELECT NOW() - INTERVAL 1 DAY
Why not use the built in DATE_SUB() function?
SELECT DATE_SUB('2013-04-01', INTERVAL 1 DAY)
EDIT: No, This is NOT a date bug in MySQL.