Recently in my day job, while developing the back-end of a reporting dashboard with PHP and MySQL, I noticed some interesting differences in DATE math calculations. The examples used in this post are purely arbitrary but stem from lessons learned, therefore, I feel they are definitely worth sharing…
OS, Software, and DB used:
- OpenSuse Leap 15.1
- MySQL 8.0.19
Self-Promotion:
If you enjoy the content written here, by all means, share this blog and your favorite post(s) with others who may benefit from or like it as well. Since coffee is my favorite drink, you can even buy me one if you would like!
My requirement was to run an analysis on specific assets based on the current date and the day before, eventually providing those query results to the front-end dashboard with PHP and MySQL. It’s quite simple using MySQL’s built-in CURRENT_DATE() function to determine what the current date is:
1 2 3 4 5 6 7 | MySQL localhost:33060+ ssl SQL > SELECT CURRENT_DATE(); +----------------+ | CURRENT_DATE() | +----------------+ | 2020-02-25 | +----------------+ 1 row in set (0.0006 sec) |
And to figure out what yesterday was? Also, quite easy. Just subtract 1 (day) from the current date:
1 2 3 4 5 6 7 | MySQL localhost:33060+ ssl SQL > SELECT CURRENT_DATE() - 1; +--------------------+ | CURRENT_DATE() - 1 | +--------------------+ | 20200224 | +--------------------+ 1 row in set (0.0005 sec) |
There is also an INTERVAL value used extensively with DATE calculations in MySQL (and other SQL dialects). Does INTERVAL provide the same results when subtracted from CURRENT_DATE() as does the standard subtraction method of – 1?
1 2 3 4 5 6 7 | MySQL localhost:33060+ ssl SQL > SELECT CURRENT_DATE() - INTERVAL 1 DAY; +---------------------------------+ | CURRENT_DATE() - INTERVAL 1 DAY | +---------------------------------+ | 2020-02-24 | +---------------------------------+ 1 row in set (0.0008 sec) |
Notice the difference?
When using INTERVAL instead of standard subtraction, we are returned an actual DATE value versus an INTEGER whole number.
Does it matter?
Well, yes it does. Mainly in comparisons.
I’ll create a couple of user-defined session variables for easier workings. This first variable, ‘@date_one’ stores the result using standard subtraction:
1 2 3 4 5 6 7 8 9 | MySQL localhost:33060+ ssl learning SQL > SET @date_one = CURRENT_DATE() - 1; Query OK, 0 rows affected (0.0005 sec) MySQL localhost:33060+ ssl learning SQL > SELECT @date_one; +-----------+ | @date_one | +-----------+ | 20200300 | +-----------+ 1 row in set (0.0006 sec) |
And the second, ‘@date_two’, stores the return value of DATE math when using INTERVAL:
1 2 3 4 5 6 7 8 9 | MySQL localhost:33060+ ssl learning SQL > SET @date_two = CURRENT_DATE() - INTERVAL 1 DAY; Query OK, 0 rows affected (0.0008 sec) MySQL localhost:33060+ ssl learning SQL > SELECT @date_two; +------------+ | @date_two | +------------+ | 2020-02-29 | +------------+ 1 row in set (0.0005 sec) |
Are they equal?
1 2 3 4 5 6 7 | MySQL localhost:33060+ ssl learning SQL > SELECT @date_one = @date_two; +-----------------------+ | @date_one = @date_two | +-----------------------+ | 0 | +-----------------------+ 1 row in set (0.0007 sec) |
No they are not.
As further proof, let’s re-assign ‘@date_one’ with the return value based off of the calculation using INTERVAL and then re-evaluate them:
1 2 3 4 5 6 7 8 9 | MySQL localhost:33060+ ssl learning SQL > SET @date_one = CURRENT_DATE() - INTERVAL 1 DAY; Query OK, 0 rows affected (0.0006 sec) MySQL localhost:33060+ ssl learning SQL > SELECT @date_one; +------------+ | @date_one | +------------+ | 2020-02-29 | +------------+ 1 row in set (0.0006 sec) |
As you can see below, this comparison result is TRUE, now that both values are calculated using INTERVAL:
1 2 3 4 5 6 7 | MySQL localhost:33060+ ssl learning SQL > SELECT @date_one = @date_two; +-----------------------+ | @date_one = @date_two | +-----------------------+ | 1 | +-----------------------+ 1 row in set (0.0007 sec) |
Hopefully, this post will serve as a reminder the next time you are performing DATE calculations and your predicate test results are a little wonky, you will have a better idea of what the cause might be.
Like what you have read? See anything incorrect? Please comment below and thanks for reading!!!
A Call To Action!
Thank you for taking the time to read this post. I truly hope you discovered something interesting and enlightening. Please share your findings here, with someone else you know who would get the same value out of it as well.
Visit the Portfolio-Projects page to see blog post/technical writing I have completed for clients.
Have I mentioned how much I love a cup of coffee?!?!
To receive email notifications (Never Spam) from this blog (“Digital Owl’s Prose”) for the latest blog posts as they are published, please subscribe (of your own volition) by clicking the ‘Click To Subscribe!’ button in the sidebar on the homepage! (Feel free at any time to review the Digital Owl’s Prose Privacy Policy Page for any questions you may have about: email updates, opt-in, opt-out, contact forms, etc…)
Be sure and visit the “Best Of” page for a collection of my best blog posts.
Josh Otwell has a passion to study and grow as a SQL Developer and blogger. Other favorite activities find him with his nose buried in a good book, article, or the Linux command line. Among those, he shares a love of tabletop RPG games, reading fantasy novels, and spending time with his wife and two daughters.
Disclaimer: The examples presented in this post are hypothetical ideas of how to achieve similar types of results. They are not the utmost best solution(s). The majority, if not all, of the examples provided, is performed on a personal development/learning workstation-environment and should not be considered production quality or ready. Your particular goals and needs may vary. Use those practices that best benefit your needs and goals. Opinions are my own.