Localization...What Day Is It?
When you need "today's date" in a client/server application, or a Web application for that matter, what date do you use? I had this discussion recently with Ed Foshko at Fidelity Investments. You might think the answer is easy - just use the appropriate function to get the date. Life as usual isn't that simple. You have at least three choices: the local computer, an application server or a database. Let's say you have an application in which you wish to capture a user's ID along with the date and time a record was updated. When the update occurs, make an entry in a logging table of some sort. This approach should enable you to determine who modified a record last...but does it? If you use the time on the user's machine and have a user in Japan modify a record followed by a user in Boston, what will the record show you? It will seem to say that the Japanese user was the last one who modified the record, although the modification won't take place until tomorrow (remember the International Date Line?). So maybe the answer is to use the time at the database. But what if the system is used to collect usage charges and the system you're using charges one rate from 9 a.m. to 5 p.m., Monday through Friday - and a lower rate the other times? In that case you need to know the local time as it'll vary according to the time zone and the use (or not) of daylight savings time. You may also be tempted to use an object on an application server. But beware if you have application servers spread around the world or in different time zones. One approach is to always use GMT and a location indicator. This allows an easy comparison of times, and with appropriate supporting tables for GMT offsets, daylight savings dates and each location you can usually get what you need. The bottom line is that localization is not just about language; it also requires some thought about dates and time...and you thought six-digit dates were the only date problem!
Ed Foshko, a software consultant and DBA, can be reached at foshko@ici.net.

A Script and Function Browser
Jane Cantz of Sybase sent me this one. This is a neat script that scans the list of system functions and displays it in a listbox. Clearly this is only one example of the kind of thing you can do. The guts of this routine is the FindClassDefinition function that takes two arguments. The first is a class name, such as a window or an nvo. In this example the class is the "systemfunctions" class, one of the standard PowerBuilder classes. You can see all the classes if you open the browser and select the system tab. This will give you a picture similar to Figure 1. The second optional argument is a library name. When you call this function it builds the class definition, which looks something like Figure 2. There are a number of variables and arrays that can provide you with all sorts of information. The one we're interested in is the scriptlist. In this example we're interested only in functions, so we'll check the "kind" of each script. Kind returns one of two enumerated variables: ScriptFunction! and ScriptEvent!. As we make our way through each function, we'll build the function prototype. Figure 3 shows the argument list. If you look for the enumerated types under "argcallingconvention", you'll see the type enumerations: ByValueArgument!, ByReferenceArgument! and ReadOnlyArgument! Listing 1 shows the functions in action. Place this script in a window with a listbox (lb_1). Jane Cantz has been at Sybase for many years.