browscap_cron uses REQUEST_TIME, its not defined in drupal 6?

Nice catch. Thanks for the bug report and patch! As you mentioned, the undefined constant is the result of code backporting from Browscap 7.x.

After reviewing your patch, I've noticed a few issues:

+  //Drupal 6 does not definde REQUEST_TIME in bootstrap.inc so define it here 

There should be a space between "//" and "Drupal", "definde" is misspelled and there is trailing whitespace.

+  if(!defined('REQUEST_TIME')){

There should be a space between "if" and "(!" and a space between "'))" and "{".

+    define('REQUEST_TIME', (int) $_SERVER['REQUEST_TIME']);

$_SERVER['REQUEST_TIME'] is only available in PHP 5.1.0 and Drupal 6 must support PHP 4.4.0.

A few other tips when contributing (much appreciated) patches:

• Review the Drupal Coding standards.
• Use the standard naming convention [short-description]-[issue-number]-[comment-number].patch.
• Always post patches against the most recent development version which contains the issue (in this case 6.x-1.x-dev).
• If you've included a patch then set the issue status to "needs review".

Attached is a modified version of the patch in #1 which:

• Moves the code to the top of the .module file.
• Expands the comment to better explain why we're defining the constant.
• Defines the constant using time() instead of $_SERVER['REQUEST_TIME'] as $_SERVER['REQUEST_TIME'] has only been available since PHP 5.1.0 and Drupal 6 supports PHP 4.x (4.4.0 or higher).
• Fixes code formatting errors and spelling mistakes.

Committed #3 to 6.x-1.x.

There are two problems with this approach:

• a constant defined in browscap.module is not available in browscap.install; hence, browscap_imported variable is not set correctly upon initial install (to reproduce, install Browscap on a fresh D6 and peek into variable table; not that it breaks anything, but it's wrong anyway);
• the whole purpose of introducing REQUEST_TIME in D7 was to extract some performance gain from avoiding multiple calls to time() in a single page request; however, if we are defining it ourselves and using only once per page request, and nobody/nothing else is using it, then we gain nothing from the whole affair.

On the other hand, some D6 contributed modules (e.g., Acquia Search) do define and use REQUEST_TIME; still, there's maybe p≈0.01 chance of 'meeting' another module that does that.

Suggested action: stop tinkering and revert to the good ol' time(). :)

Patch to that effect attached.

#6 sounds fine to me. Committed and pushed to 6.x-1.x.