A common question from people creating web-based VuGen scripts is how to handle timestamp values that are sent as part of a name/value pair in an HTTP request.

If we look at the example GET request below, two values immediately stand out as needing to be correlated.


The jsessionid should be easy to correlate, but the ts value usually causes some confusion.

An experienced eye will notice that 1231715057375 looks like a timestamp in Unix Time, which is defined as the number of seconds since 00:00am on January 1, 1970. An even more experienced person will notice that the number is actually in milliseconds, rather than seconds, so it is probably being generated with the JavaScript getTime() method.

In this case, 1231715057 translates to Sun, 11 Jan 2009 23:04:17 UTC.

As this value is being generated on the client (i.e. the web browser), it will be impossible to correlate, because the actual value never appears in the HTML that is returned by the web server before the value is used in a request.

The solution is to create the timestamp value in your VuGen script at runtime, rather than trying to correlate the value.

// Using standard C library functions to get timestamp in seconds.
long t;
lr_save_int(t, "secondsTimeStamp");
lr_output_message("Seconds: %s", lr_eval_string("{secondsTimeStamp}"));

Using a LoadRunner function to get timestamp in milliseconds.

Function documentation:
web_save_timestamp_param saves the current timestamp. 
In some applications, VuGen replaces all non-empty timestamps in the script with a parameter. 
To save the value of this parameter, VuGen automatically generates a call to 
The value saved is the number of milliseconds since midnight January 1st, 1970. */
web_save_timestamp_param("msTimeStamp", LAST);
lr_output_message("Milliseconds: %s", lr_eval_string("{msTimeStamp}"));

As creating a timestamp value is so easy to do, there is no excuse for leaving hardcoded values in your VuGen script from your initial recording, even if the script seems to run without error.

Tech tips from JDS



How to substitute the millisecond value captured in the tags?

We tried using {value} , which is not working

Try lr_save_timestamp to get a timestamp in seconds – it is more powerful than web_save_timestamp_param.

My documentation for the function:

int lr_save_timestamp( const char* tmstampParam, [DIGITS,] LAST );

The name of the parameter to store the timestamp.

Optional. The number of digits for the timestamp (integer). The default is 13 (epoch time including 3 digits of millisecond precision).

If the value of DIGITS is less than 1 or more than 16, the default is used

In this example, the timestamp is saved and a length of 10 digits is specified. Get epoch time in seconds

lr_save_timestamp(“param”, “DIGITS=10”, LAST );

Is it possible to get the 13-digit timestamp value for future date or past. We are failing to store it to any of variable format like int/long int…

Franklin Inbaraj

Useful stuff. Get seconds directly rather than converting from milliseconds :)

Hi Folks,

I have encountered a problem where the Timestamp captured in the script is in EDT timezone where as the functions like web_save_timestamp_param and time_t captures timestamp in UTC/GMT. Any Solution or fuction that can be used to resolve this.


Concise and exactly what I needed. Thanks

Good article Stuart! I found a EPOCH time conversion routine in ‘C’ which has proven successful many a times. But I will try this solution sometime too…

Anustup Ray


I am facing a correlation problem. The problem is the dymanic value needed to correlation occurs at the first letters of the html returned by the server. The problem is that there is no LB because the HTML starts with the dymanic value. I tried to leave the LB blank but then the parameter is not capturing anything. Any ideas about this?


Stuart Moncrieff

Interesting piece of trivia…

On Friday the 13th, 2009 at 11:31:30pm UTC UNIX time will reach 1,234,567,890.

…and just after 03:14:07 UTC on Tuesday, 19 January 2038, the 32-bit integer that stores the timestamp will roll over to -2147483648. This is known as the “Unix Millennium bug“.