Browse Prior Art Database

Improved Reusable Natural Calendar

IP.com Disclosure Number: IPCOM000023224D
Original Publication Date: 2004-Mar-29
Included in the Prior Art Database: 2004-Mar-29
Document File: 3 page(s) / 50K

Publishing Venue

IBM

Abstract

An improved reusable Natural Calendar implementation is described. This improved implementation reduces the number of object instances and data/cache size while retraining the same level of flexibility and reusability.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 1 of 3

Improved Reusable Natural Calendar

A key element of many business applications is the 'natural' calendar that allows them to manage data associated with days of the week and to perform calculations related to their working days. For example, to be able to tell a customer when an order will be shipped, the business must be able to use the number of working days to package (collect together and box) the order and apply it to the days they work (or possibly the hours they work). So given that it takes 5 working days to package the product, if today is Friday (12/5) and we don't work Saturday (12/6) or Sunday (12/7), then the soonest we can ship it is next Friday (12/12). If Monday (12/8) of next week happens to be a holiday, then it would be the next Monday (12/15). There are other calculations of interest such as lead-time -- how soon do we have to start on the order so that we can ship on a certain date, elapsed time -- how many working days between two dates, and calculating the number of days employees worked in a specific time frame, such as 1/1 to 12/31.

    The requirement is to provide a reusable design and implementation that can be used to use to build into applications. Our original implementation was to create a set of seven default days each indicating if they are working days or not (and possibly the working hours). In our example, we would create Monday-Friday and indicate they are working days and Saturday and Sunday and indicate they are non-working days. We then created a collection of years with each year containing a collection of calendar dates which were associated with one of the particular default days. For holidays, a non-default day is created and the calendar date changed to associate with it. Thus, in our example, we'd have the 2003 calendar with all the calendar dates in it. 12/5 would be associated with the default Friday, and so on. If 12/8 is a holiday, it would be associated with a new day that indicates it is a non-working day and (optionally) describes the holiday. So in our example calculation, we would look up the calendar date for 12/5, look at its data and then iterate looking at each subsequent calendar date until we'd found 5 working days. We also did a number of things such as enumerate the calendar dates so that we could optimize a number of the calculations (such as being able to simply subtract each date's enumeration to calculate the elapsed days). When we moved this design to Java 2 platform, Enterprise Edition (J2EE*), we discovered that our design no longer provided the needed performance. Even the changing the original design to take advantage of Enterprise JavaBeans* 2.0's Container Managed Relationships wasn't enough. We needed to go back and create a new design.

    While designs are usually hidden from the customer, the intent of providing this in a reusable form is for the independent software vendor to modify it to their particular needs. To support this, a number of the processes assoc...