Related Links

• DB2 Date Functions
• Informix Date Manipulation
• MySQL Date and Time Functions
• Oracle Date Functions
• Dates and Times in Teradata
• SQL Server Datetime functions

External links are provided without endorsement and may become inactive at any time. These links were functioning properly at the time this blog post was published but dagira.com has no guarantee that they will continue to be available.

This is the fourth in my series about dynamic date objects. The first three included objects for daily, weekly, and then monthly ranges. I am going to complete my collection of Oracle-based dynamic date objects by providing yearly objects in this post.

Current Year

In the monthly post I showed how the Oracle trunc() function can be used to truncate (remove) everything except for the year and month. Here’s how to apply the same technique and get the first day of the year:

trunc(sysdate,'YYYY')

The formula shown above will “round off” the date to the year. Since the return value for this function has to be a date, Oracle returns the year + first month month + first day of the year. Short and simple. I have seen other formulas that convert a date to a string, extract the year with a substring operation, and then combine it back with ‘01′ for the day and ‘01′ for the month and then convert it back to a date. My advice? Use the trunc() function.

Readers that have followed this complete series will not be surprised with where I go to get the end of the current year. I could get the year from the current date (using string functions as outlined in the prior paragraph) and add in December and 31 for the day. Instead I will use this:

last_day(add_months(trunc(sysdate,'YYYY'), 11))

The advantage of this formula is that everything is based on date math. When I convert a date to character data and then use character functions there is a chance that the result value won’t be a valid date unless I do a lot of error checking. This way is fairly simple.

Why do I apply the trunc() function first? I do that to get to a constant starting point. Get to a known point and the offset (11 months) is always the same.

Last Year

As before I will be setting up objects for the prior year as well. This time instead of using the @Select() function I will do something slightly different. I will give you lots of options.

What About Fiscal Calendar Years?

As I said in the prior post on monthly date ranges I would have to use a period calendar table or write custom database functions in order to create fiscal year objects. The standard Oracle database functions work only on a standard calendar. If you have a fiscal calendar and require dynamic yearly dates I strongly suggest that you look at creating a calendar table that supports your requirements. Note: I won’t be covering that process in this series of posts.

Summary

Over the past four posts I have built daily, weekly, monthly, and now yearly dynamic date objects. All of the prior posts in this series are conveniently linked below in case you missed one. What’s next? I realize that not everyone uses Oracle. Some of these formulas can easily be converted to other databases, and some are more challenging. I will try to show some of these same formulas in other databases. I don’t plan to try to do every date range for every database but will try to cover samples of each.

Remember that these objects are presented will not parse in Designer. They don’t reference a table and therefore will generate an error. As long as these objects are used with at least one “real” object on a query they will function perfectly fine.

Related Posts

• Dynamic Dates Part I: Yesterday and Today
• Dynamic Dates Part II: Weekly Date Ranges
• Dynamic Dates Part III: Monthly Date Ranges
• All posts in this series

Oracle functions used in this post

• add_months() Returns an offset in months ahead or behind from the date given
• last_day() Returns the last day of the month for the date given as an argument
• trunc( , ‘YYYY) Returns a date value truncated to the first date of the year

Dynamic Dates With Oracle Functions

In the first post in this series I introduced the idea of dynamic date objects. The intent was to show how a universe designer can create dynamic date objects that can be used to schedule reports with a condition that changes over time. The first post covered the basic concepts and included “Today” and “Yesterday” dynamic date objects. The next post covered weekly ranges. In this post I will further extend the concept to monthly ranges. As with the other posts so far in this series I will be using Oracle functions.

Working In the Current Month

Getting the first date of the current month is really simple with Oracle. There are a number of different ways but here is what I think is the simplest method:

trunc(sysdate,'MM')

I mentioned before that trunc() is an overloaded function. So far in this series I have used it only to remove the time portion of a date/time value. By adding an additional argument I can remove more than the time element from the date. The formula shown above will “round off” the date to the month and year. Since the return value for this function has to be a date, and every date must have a day value, Oracle returns the year + month + the first day of the month. How convenient.

The end of the current month is harder, if only because months have a different number of days. Personally, I use the knuckle trick to remember which months have 30 versus 31 days. Since Oracle doesn’t have hands I need a different approach. I could use a case statement to check which month I am in and determine the number of days in the month using something like this:

case to_char(sysdate,'MON')
when 'JAN' then 31
when 'FEB' then 28
when 'MAR' then 31
when ...
when 'DEC' then 31
end

That is a lot of code to write, and it doesn’t handle leap years. As it turns out there is a much easier way to approach this. All I need to do is recognize what the last day of every month has in common. It doesn’t matter if the day number is 28, 29, 30, or 31, there is always one constant: The day after the last day of one month is always the first day of the following month.

I can use the trunc() function to get the first day of this month. How can I get the first day of next month? I could try adding 30 days and then truncating, but that would still require me to know how many days are in each month in order to check the boundary conditions. It should not be that hard, and it turns out that I can get to the last day of a month using a new function called add_months().

Finding the End of a Month

Here is the syntax for the add_months() function:

ADD_MONTHS(<date>, <number_of_months>)

The number_of_months can be either a positive or negative integer. This allows me to move either forwards or backwards for as many months at a time as are needed. What can I do with this? Suppose that I get the first day of this month, add one month to that date, and then subtract one day? Where do I end up? I end up on the last day of this month. I take something constant (the first day of a month) and use it to derive something that is dynamic (the last day of the month) with a little creative math.

So here is some code for an object named Last Day of Current Month that uses the add_months() function and the logic outlined in the prior paragraph:

add_months(trunc(sysdate,'MM'), 1) -1

This formula works for every month of the year, and every possible scenario of leap year as well. It will handle moving across a year boundary (December – January). It will handle the fact that some months have different numbers of days… for example, if I add one month to January 31 I will get February 28 (or 29 as appropriate). It will not add 31 days since January has 31 days. Here is a table showing some output from an Oracle query that shows what happens when I cross a month boundary using this function:

August has 31 days. September has 30. Notice what happens on August 31 when I add one month to the date? I get September 30, which is what I want to see. What Oracle does is provide a mapping of “last days” so that you get the expected results without having to do a lot of specific date checking. Adding a negative month also works as expected, which becomes important when I try to create objects for last month.

It’s All About the Creative Process

If you read and understood everything in the prior section, that’s great. Now throw it all away.

The formula that I showed using add_months() works. It dates back to my early days as an Oracle developer. The need to find the last day of a month is so important that several versions back (I think in version 8? but I am not sure…) Oracle gave us a function to do exactly that. The function name, oddly enough, is last_day() and here is the syntax:

LAST_DAY(<date>)

Short, simple, and to the point. As I was writing this post I thought about skipping the add_months() example. I went ahead and included it to show the “creative process” that I try to apply to find an alternate path when no immediate solution presents itself.

And for Last Month?

I don’t want to stop after handling the current month. I want to be able to provide dynamic dates for the starting and ending dates for last month too. As I did in the weekly post I will use the @Select() function to reference the complex expressions that I have created so far and then subtract one month as shown here. To get the end of last month no matter how many days there are in “this” month I will apply the last_day() function again.

add_months(@Select('Dynamic Dates\Start of This Month'), -1)
last_day(add_months(@Select('Dynamic Dates\Start of This Month'), -1))

That’s all there is to it.

What About Fiscal Calendar Periods?

In order to provide dynamic dates for a fiscal calendar I would have to use a period calendar table or write custom database functions. The standard Oracle database functions work only on a standard calendar. If you have a fiscal calendar and require dynamic monthly dates I strongly suggest that you look at creating a calendar table that supports your requirements. Note: I won’t be covering that process in this series of posts.

Summary

Over the past three posts I have built daily, weekly, and monthly dynamic date objects. I did not cover how to use these objects in a query in this post but I did in the first post, which is conveniently linked below. Remember that these objects are presented will not parse in Designer. They don’t reference a table and therefore will generate an error. As long as these objects are used with at least one “real” object on a query they will function perfectly fine.

I still have a few more posts to go before I wrap up this series. The next post will be fairly simple as it will include standard objects for working with the current year and prior year date ranges. You won’t have to wait until next year for that one to come out.

Related Posts

• Dynamic Dates Part I: Yesterday and Today
• Dynamic Dates Part II: Weekly Date Ranges
• All posts in this series

Oracle functions used in this post

• add_months() Returns an offset in months ahead or behind from the date given
• last_day() Returns the last day of the month for the date given as an argument
• to_char() Converts a date into a string value with a wide variety of formats
• trunc() Returns a date value with the time truncated off
• trunc( , ‘MM’) Returns a date value truncated to the first of the month

Dynamic Dates With Oracle Functions

In the first post in this series I set up both regular objects and predefined condition objects that were based on the Oracle sysdate pseudo-column. These objects were designed to be used for scheduling reports with date conditions while allowing the date range to move forward in time for each new execution of the scheduled report. For that article I only created objects for Today and Yesterday. Today I will provide some weekly date ranges with the help of a few Oracle functions.

Yesterday Once More

Here is a review of what I ended up with for my daily objects in the prior post.

Where can we go from here? It turns out that time travel is possible, given the right functions.

Weekly Dates

The first thing I need to decide is when my week starts. I will use a calendar where the week starts on Sunday and ends on Saturday. The function that I will use to derive those dates is called next_day(). The syntax for this function is:

NEXT_DAY(<date>, <day of the week>)

What this will do is take the input date and return the date of the “next” day based on the second function parameter. Let’s suggest that today is Tuesday. The next Saturday ( the end of the week) would be four days away. You could write a fancy case statement to determine that, but the next_day() function takes all the effort out of it. Simply write this:

next_day(trunc(sysdate), 'Saturday')

And the next thing you know, you have the date for the end of the current week. Or do you?

Testing the Boundaries

With any condition that involves a range it is important to check the boundaries. For example, what is the return value for the function outlined above if today is already Saturday? Unfortunately, it isn’t the correct Saturday. Instead, it will be the Saturday that ends the following week. That means that we have a formula that works for 6 out of the seven days of the week. How can I know that it is Saturday? I need a new function.

For this I will use the to_char() function. I don’t care what the date is, but I do need to know what the day is. The formula for that is:

to_char(sysdate,'Day')

If today is a Saturday, then the return value for this function is the day name Saturday. There are different argument options that can be used here… for example using ‘Dy’ instead of ‘Day’ would return Sat instead of Saturday. Either works for this purpose.

Now that I have a way to know if it is Saturday or not, I can handle my boundary condition. There are a couple of things that I can do. I have opted to check to see if it is Saturday, and if it is, back up one day before applying the next_day() function. Backing up one day changes sysdate to a Friday, and then the “next” Saturday would be the required date instead of a week later. Here’s the completed formula:

next_day(case to_char(sysdate,'Day') when 'Saturday' then trunc(sysdate-1) else trunc(sysdate) end, 'Saturday')

That code can be used to create an object called End of Current Week. This object can then be used in conditions as I outlined in the first post in this series.

Start of Current Week

To get to the start of the week I might like to use a previous_day() function. However Oracle does not provide that. Not to worry, there is a very simple solution. All I need to do is back up 7 days and then apply the next_day function to get the Sunday date that starts the current week.

next_day(trunc(sysdate-7), 'Sunday')

Since I had an issue with Saturday boundary condition I want to also check what happens on Sunday using the above formula. It turns out that we don’t have a problem. If today is any day other than Sunday, and I back up 7 days, then the next Sunday is the proper date. What if my current date is actually Sunday? After I back up 7 days, the “next” Sunday just brings me right back to where I started from. So while it might seem like extra work to go back a week just to come back to the same date value, the simple formula as posted above works just fine on the Sunday boundary condition.

Here is some sample data that shows what the output from these formulas will look like over a few weeks of data:

I (Want to) Know What You Did Last Week

Knowing what happened this week is interesting. But I won’t stop here. It is often more interesting to know what happened last week, since that week is done and in the books. So I would like to make objects named Start of Last Week and End of Last Week. Since I have the objects for this week built, the objects for last week are trivial. Here they are:

Start of Last Week
@Select('Dynamic Dates\Start of This Week') - 7

End of Last Week
@Select('Dynamic Dates\End of This Week') - 7

I plan to talk more about the @Select() function in a future post. For now I will just say that it is used to copy the select clause from another object referenced by the ‘Class Name\Object Name’ format. Since the Start of Last Week is exactly 7 days prior to the Start of This Week, I think that this is a perfect opportunity to use that feature. Since I have already created the complicated formulas for the start and end of the current week, I can reuse them / adjust them for the last week values as well. Using this function means that future changes to the objects for this week will be inherited by the objects for last week at the same time.

Summary

I can easily extend the formulas that I have provided so far. At this point I have a Dynamic Dates class that contains objects for Today, Yesterday, Start of This Week, and End of This Week. To do “next week” I would add seven days to the current week objects instead of subtracting. If I wanted to be creative I could prompt the user for the “number of weeks” and end up with a set of objects that would allow a report to run for 2 weeks ahead or 3 weeks prior just by changing a prompt value. All of these objects are based on sysdate and therefore can be used to provide dynamic date conditions for any sort of report. Their expected use is for scheduled reports but I cannot see anything wrong with using them interactively as well.

Remember that these objects as presented will not parse in Designer. They don’t reference a table and therefore will generate an error. As long as these objects are used with at least one “real” object on a query they will function perfectly fine.

Days and weeks are generally the same no matter what type of calendar is being used. In the next post in this series I will talk about how to work with monthly boundaries. If you need to work with fiscal periods you will have to include a calendar table of some sort, but I can do months with standard functions. That post will be published… next month.

Related Posts

• Dynamic Dates Part I: Yesterday and Today
• All posts in this series

Oracle functions used in this post

• next_day() Returns the date of the next day based on the provided day name argument
• to_char() Converts a date into a string value with a wide variety of formats
• trunc() As used in this article it returns a date value with the time truncated off

Dynamic Dates With Oracle Functions

Does anybody really know what time it is?
Does anybody really care?
If so I can’t imagine why…

With apologies to the rock group Chicago, but I could not help starting out this post with a quote from one of their most famous hit records. Yeah, I have records. Deal with it.

I am going to start out this post with a very obvious statement. There are two ways to get reports: Interactive and Scheduled. Interactive reports can have prompts that allow me to specify which values I want to see, and many times those prompts will include dates or date ranges. Since they are interactive I can change the dates each time I run the report.

But what about scheduled reports? I would hardly want to schedule a report that always ran for August 22, 2007, right? I want that date parameter value to change. Maybe I want the report to always run for “yesterday” or “last week” or “the second Tuesday of the month” or anything along those lines. The challenge is, of course, that the value for “yesterday” changes each day I run the report. How do I hit that moving target?

It’s All About Today

The first component that I need to solve this issue is knowing what “today” means for any given database. Every system that I have worked with has provided at least one mechanism to get today’s date:

Some databases use a function and others provide a token or pseudo-column instead. I am going to use Oracle syntax for the rest of this post but the general concepts and techniques that I plan to show are often able to be ported to other database systems.

Using sysdate

As mentioned I can get today’s date from Oracle using the pseudo-column sysdate. (It’s called a pseudo-column because you can get it from any table in the database.) Once I know what today is I can derive other interesting values. The first step is often to get only the date (instead of a full date/time result) and the Oracle function trunc() takes care of that. So today can be obtained by:

trunc(sysdate)

The trunc() function in Oracle is an overloaded function which means I can use it with a variety of different syntaxes. (It may be that I could create a more portable version of the same objects using the cast() function.) Now that I have today, what can I do with it? I mentioned earlier in this post that one of the common requests is to be able to run a report for “yesterday” on a scheduled basis. Yesterday is the day before today on most calendars. So I can create an object for “yesterday” using either of the following:

trunc(sysdate-1)
trunc(sysdate)-1

Both of these will return the exact same result, so it doesn’t matter which one I pick. I am going to use the first one for reasons that will be detailed in a future blog post.

Conditions in a Scheduled Document

Once these objects are created I have a couple of options to consider. First, I can make predefined conditions that are based on a specific date object like Order Date or Shipped Date. I will often do this for frequently used conditions. But an important option that should not be overlooked is creating a simple object called Yesterday with the code posted above. After this object is created then I can create any date condition, using any date object in the universe, by using the “Select an Object” query operand. This option is available in full client from version 5.x forward (and possibly in version 4.x too, I don’t remember). It is also available in Web Intelligence XI and might be in 6.5.

I will create Today and Yesterday objects using Oracle as my target database. Here are the objects:

And here is the result I get when I parse either of these two objects:

This is typical! Most if not all of my objects built for this strategy will fail to parse. One of my current universes has several hundred objects that fail to parse during a universe integrity check, and that is just fine. I don’t want to reference any table with these objects (not even the special Oracle “dual” table) because then I would be limited as to how I can use them. If I use the dual table and don’t include any joins then I would get Cartesian warnings. Objects like this are perfectly safe to use as long as they participate in a query with at least one object that does use a real table. And since these objects would never be used by themselves that is okay.

Now that I have my objects built, here’s how I will use them. I am going to build a condition that will return all orders entered yesterday by using the following steps.

1. Create a condition on Order Date Equal to and select Object from the condition operand options.

   

2. Browse the universe to my Dynamic Dates for Scheduling class and select Yesterday.

   

3. Confirm the selection and review the condition.

   

That generates a condition that looks just perfect for my purposes. The order date will be compared to a dynamic “yesterday” object. Since that object is based on the system date then that object will change in value on each new daily execution of the scheduled report. If order dates are date/time values then to get the full range I can use a between operator instead. For this I need both of my dynamic date objects, as shown next. This condition will return everything from midnight yesterday to midnight today.

What does the SQL code look like?
SELECT
CUSTOMER.CUSTID,
...
sum(ORD.TOTAL)
FROM
CUSTOMER,
ORD
WHERE
( CUSTOMER.CUSTID=ORD.CUSTID )
AND
ORD.ORDERDATE BETWEEN trunc(sysdate-1) AND trunc(sysdate)
GROUP BY
CUSTOMER.CUSTID

The condition added to the where clause by this condition is bold to try to make it stand out more. I can see that there is no specific date in the query, therefore as the report instance is executed on its daily scheduled basis I will get what I expect: a daily report with orders from yesterday.

Predefined Conditions

The biggest advantage to creating the general date objects is that they can be used to compare against any other date object in the universe. Of course I can also consider creating predefined condition objects in my universe. These objects are often built for conditions that are too complex for users to create, or there is a need for consistency across all reports, or for convenience. But in this case the number of predefined condition objects could become a challenge.

I would have to create a cross product of date objects, dynamic date elements, and desired date operators. That’s a lot of predefined conditions in my universe! So far I have two dates (order date and ship date) and two dynamic elements (today and yesterday). I could have:

1. Order Date Equal To Today
2. Order Date Equal To Yesterday
3. Order Date Between Yesterday and Today
4. Order Date … ?

As you can see it could get out of hand. And all of the conditions above can be created by the user with the proper query techniques if I just build the dynamic objects. In theory you could build a huge set of predefined conditions. In practice I generally will build one or two that are used frequently and let the user do the rest. So I will create objects for orders placed yesterday and for orders shipped yesterday and leave it at that until I get requests for something different.

Summary

This is one of the standard elements of any universe that I design. This post is designed to introduce the concepts. The next post in this series will cover some more Oracle-specific date functions and how they can be used to do very creative things with dynamic date objects for scheduling.

Oracle functions used in this post

• trunc() As used in this article it returns a date value with the time truncated off