After last time’s functions for extracting information from a date, I’ll look into some real date math, with functions that perform some neat tricks.

It’s now time to let the system do the so-called “date math” for you. This is an easy task in SQL because there are several intuitive functions to help. Let’s start with ADD_MONTHS. This function has two parameters: a valid date representation and the number of months to add. Here’s an example:

SELECT      ADD_MONTHS(‘2015-02-03’, 1)

FROM        SYSIBM.SYSDUMMY1

This statement returns ‘2015-03-03’, a month after the original date, because I specified 1 in the second parameter.

You know that when it comes to date calculations, things can get a bit strange, so let’s be clear about a few rules. First, if the input date is the last day of the month or if the resulting month has fewer days than the day component of the input date, then the result is the last day of the resulting month. Otherwise, the result has the same day component as the input date, as in the example presented. Fortunately, the second parameter also accepts negative integers, so you can use ADD_MONTHS to subtract months. Second, if you want to know how many months elapsed between two dates, ADD_MONTHS won’t help, but MONTHS_BETWEEN will.

This SQL time-saving function has two input parameters; let’s call them Date 1 and Date 2. The function expects two valid date representations in the usual formats, and it returns a DECIMAL(31, 15), containing the number of months between the dates. Note that if Date 1 is greater than Date 2, the returned decimal is a positive number; otherwise, it’s negative.

Those are the obvious calculation rules. The rest are not so straightforward and deserve a little explanation. If Date 1 and Date 2 represent dates with the same day of the month (or the last day of the month) or both parameters represent the last day of their respective months, the result is a the whole number difference based on the year and month values, ignoring any time portions of timestamp arguments. Otherwise, the whole number part of the result is the difference based on the year and month values. The fractional part of the result is calculated from the remainder, based on an assumption that every month has 31 days. If either input date represents a timestamp, the parameters are effectively processed as timestamps with precision 12, and the time portions of these values are also considered when determining the result.

Here is a statement to help you understand these rules:

SELECT      MONTHS_BETWEEN(‘2015-02-03’, ‘2015-01-03’)

            , MONTHS_BETWEEN(‘2015-01-03’, ‘2015-02-03’)

FROM        SYSIBM.SYSDUMMY1

The first part of this statement returns 1.000000000000000- because Date 2 is smaller than Date 1. The second part returns 1.000000000000000. Yes, the return value has all those zeros; remember that this function returns a DECIMAL(31, 15) value. IBM’s DB2 for i Reference Manual provides additional examples, shown in the table below.

(1) The value in days is calculated using the following formula:

ROUND(MONTHS_BETWEEN(Date1, Date2)*31,2)

(2) The time difference is ignored because the day of the month is the same for both values.

(3) The result is not 23 because, even though February has 28 days, the assumption is that all months have 31 days.

(4) The result is not 33 because both dates are the last days of their respective months, so the result is based only on the year and month portions.

There’s another function involving months, but it has a much simpler objective: returning the last day of the month. There was an RPG Academy TechTip that readers found controversial, again because SQL would be a better solution for the problem at hand. You can read that article here. Well, the readers were right, of course. SQL function LAST_DAY does something similar, using a single statement:

SELECT      LAST_DAY(‘2015-02-03’)

FROM        SYSIBM.SYSDUMMY1

This function takes a valid date representation as its only input parameter and returns the date of the last day of the given month, taking into consideration the month and, in February’s special case, the year. This example returns ‘2015-02-28’. If I wanted the exact same output as the LastDayOfMonth RPG function from the aforementioned RPG Academy TechTip, I’d have to use another function to extract the day part of the date. There are several options for this: DAY, DAYS, DAYOFMONTH, and EXTRACT. I’ll go with the DAYOFMONTH:

SELECT      DAYOFMONTH(LAST_DAY(‘2015-02-03’))

FROM        SYSIBM.SYSDUMMY1

This nesting approach returns the last day of February 2015, the 28th, which, by the way, was a Saturday. We humans sometimes make appointments based on the day of the week—things like “we’ll meet next Thursday at 2:00 p.m.” or “see you for lunch next Monday.” These are easily understood by humans, but present a challenge when you try to code them. SQL has a function that helps with that.

The NEXT_DAY function accepts two input parameters: a valid representation of a date and a string expression representing a day name in regular or abbreviated form. For instance, “MONDAY” and “MON” are equally acceptable, assuming the system language is English. The function takes these two parameters and returns the date corresponding to the named day (from the second parameter) that occurs after the input date (from the first parameter). Let’s look at an example:

SELECT      NEXT_DAY(‘2015-03-02’, ‘SUN’)

FROM        SYSIBM.SYSDUMMY1

This returns ‘2015-03-08-00.00.00.000000’. According to my computer’s calendar, that’s the first Sunday after March 2, 2015. If you prefer a date instead of a timestamp, just convert NEXT_DAY’s output to a date:

SELECT      DATE(NEXT_DAY(‘2015-03-02’, ‘SUN’))

FROM        SYSIBM.SYSDUMMY1

Pretty neat, isn’t it? And also a bit tricky to do in RPG!

This concludes the part of the SQL 101 series dedicated to SQL functions. By no means is this a complete and thorough review of all SQL functions. It focuses on some of the string and date functions that are most useful or most interesting. IBM’s DB2 for i Reference Manual contains the complete list of functions. If you ever run into something that you’re not able to handle with the functions explained in this series, go have a look!

Next time around, I’ll talk about the tools you can use to write and run SQL statements, starting with the old and reliable STRSQL green-screen command. Until then, share your questions and remarks in the Comments section below or in the LinkedIn groups where SQL 101 TechTips usually pop up.