Crystal Reports: Date Serial Function

We have been using the Date(y,m,d) function for many years. It has become a habit to use these, instead of date literals.

 We always wrote our formulas so the month number was in the range of 1 to 12 and the day number was valid for that month. We recently discovered the DateSerial function, which behaves in a similar way--but is more tolerant.

A value larger than 12 or less than one will still calculate a valid month, and will adjust the year correctly.

Use DateSerial(Year(CurrentDate),Month(CurrentDate) + 6,1) and you will get the 1st of the month in 6 months time. Subtracting months also works as required.

Days work in a slightly different way. A value of 0 gets the last day of the previous month. This makes sense if you think that 1gives you the first of the month, so 0 must get the day before.

A related topic is date conversion. Here's some good information for dealing with that.

One of the formats we were asked to convert was a date that was stored in a string field as ddMMMyyyy (for example 10 of January was stored as 10JAN2003). This field can be converted to a date and used in calculations.

The formula you need is 
Cdate (Picture({table.field},”xx-xxx-xxxx”) 

The Picture function isn’t widely used, but it can be useful in this case to add the required punctuation to the string. CDate is a powerful function that can take a string value that looks like a date and convert it to a date value. 

Just be careful if you have D-M-Y or M-D-Y numeric formats as these could cause some confusion (01-10-2003 is January for a US reader, but October for the rest of the world).

What's that all about, anyhow? Well....

In the United States, many companies use the format MM/DD/YYYY. For example, they write 09/11/2001 and say "September 9, 2001." And it's become popular in the USA to refer to this date as "911."

What's interesting about this is the airlines use a different format. They use DD/MM/YYY. So does the military. So does most of the rest of the world.

Suppose you are communicating with someone who does business internationally and ask for an item to be delivered "on 03/09/2006." When can you expect that item to arrive? You may be thinking you are going to get it on March 9th. But, the other person reads this as 03 September.

What can you do to avoid problems? A commonly accepted solution is to use MMM to indicate the month. Three upper case letters in a date format means you are using a three-letter designation for the month. For example, 03SEP2006. There's no confusion as to what month you can expect delivery.

This method of mixing alpha and numeric solves a communication problem quite handily. But what about inside a database or spreadsheet, where you need to do calculations with dates? It's a bit hard to subtract FEB from NOV, now, isn't it? So how do you guarantee you are going to get the month and the day in the correct order?

In software--especially in databases, file systems, and spreadsheets, another format is fairly standard and it solves that problem. You'll also see this format in inventory systems and many other tabular style applications. That format is YYYY-MM-DD. A variation is YYYYMMDD.

So, it will look like this: 20060903. The largest unit (years) are on the left, and the smallest units (days) are on the right. Why not do it the other way? Well, you could. But what if you wanted to sort by date? Or perform a calculation that involved different months or years?

To avoid confusion:

• Use the YYYYMMDD format when working with data.
• Use the DDMMMYYYY format when working with information.
• Don't use the MMDDYYYY format at all.

To avoid related confusion:

• Always use four digits for the year, not two.
• Always provide a legend for a date mask, when you are forcing the format for data validation purposes.
• When providing a legend for a date mask, remember that lower case letters indicate hours, minutes, and seconds: YYYYMMDDhhmmss.

If you are using the 12-hour clock, you should consider going to a 24-hour time standard. This also avoids confusion, especially if you run a multishift or 24-hour operation.

This article is copyright 2004 Chelsea Technologies Ltd. It may be freely copied and distributed as long as the original copyright is displayed and no modifications are made to this material. Extracts are permitted. The names Crystal Reports and Seagate Info are trademarks owned by Business Objects.