|
|||||||||
|
Crystal Reports Tools: Improve Performance While Saving Time and Money |
|
Crystal Reports: Date ConversionEven with Y2K problems now a distant memory, we still find databases that store dates in various formats. If you can identify the rules that the format uses, you can usually design a formula to convert the field to a date so you can perform date calculations. 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 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:
To avoid related confusion:
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 copyrighted by Crystalkeen, Mindconnection, and 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. |