WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.
WinRunner enables you to handle the following types of exceptions:
Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.
TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific error code.
Object exceptions: Instruct WinRunner to detect and handle a change in a property for a specific GUI object.
Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and errors that occur in your Web site during a test run.

A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be
Default actions: WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.
User-defined handler: If you prefer, specify the name of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.
The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You implement this function to respond to the unexpected error in the way that meets your specific testing needs.
Once you have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.

1) Use get-time to get the PC system time in seconds since 01/01/1970
2)Subtract 86400 (no seconds in a day) from it
3)Use time_str to convert the result into a date format
4)If format of returned date is not correct use string manipulations to get the format you require
5) Insert the date into your application
Alternatively you could try the following :
1) In an Excel datasheet create a column with an appropriate name, and in the first cell of the column use the excel formula 'today() - 1'
2) Format the cell to give you the required date format
3) Use the ddt- functions to read the date from the excel datasheet
4) insert the reteived date into your application

You can have scripts that run for different locales.I have a set of scripts that run for Japanese as well as English Locales. Idea is to have objects recorded in GUI Map with a locale independent physical description. This can be achieved in two ways.
1. After recording the object in the GUI Map, inspect the description and ensure that no language specific properties are used. For ex: html_name property for an object of class: html_text_link could be based on the text. You can either remove these language dependent properties if it doesnt really affect your object recognition. If it does affect, you need to find another property for the object that is locale independent. This new property may be something thats already there or you need to create them. This leads to the next option.
2. Have developers assign a locale independent property like 'objname' or something to all objects that you use in your automated scripts. Now, modify your GUI Map description for the particular object to look for this property instead of the standard locale dependent properties recorded by WR (these default properties are in GUI Map Configuration).
or
You could also use a GUI map for each locale. Prefix the GUI map name with the locale (e.g. jpn_UserWindow.gui and enu_UserWindow.gui) and load the correct map based on the current machine locale. Specifically, you can use the get_lang() function to obtain the current language setting, then load the appropriate GUI map in your init script. Take a look at the sample scripts supplied with WinRunner (for the flight application). I think those scripts are created for both English and Japanese locales.

After taking care of different GUIs for different locales, the script also needs some modification. If you are scripting in English and then moving on to any other language (say Japanese), all the user inputs will be in English. Due to this the script will fail as it is expecting a Japanese input for a JPN language. Instead of using like that, assign all the user inputs to a variable and use the same wherever the script uses it. This variables has to be assigned (may be after the driver script) before you call the script which you want to run. You should have different variable scripts for different languages. Depending on the language you want to run, call the appropriate variable script file. This will help you to run the same script with different locale

Several web page windows with similar html names - they all end in or contain "| MyCompany" The GUI Map has saved the following physical description for one of these windows:
{
 class: window,
 html_name: "Dynamic Name | MyCompany"
 MSW_class: html_frame
}
The "Dynamic Name " part of the html name changes with the different pages.
Replace:
{
 class: window,
 html_name: "!.*| MyCompany"
 MSW_class: html_frame
}
Regular expressions in GUI maps always begin with "!".

If WinRunner is not learning sub-items then the easy way id to add manually those sub items in to GUI map.. of course you need to study the menu description and always add the PARENT menu name for that particular sub-menu..