LicenseMonitor must be timezone-aware in 2 different situations:

1.  When parsing a debug log that was generated in a different timezone:

The debug log parser is executed locally on the LM server using the servers local timezone by default.  The debug log contains date/time information that was generated using the timezone of the remote server.  In the configuration, you can specify a timezone for the debug log.  What we do is run the debug log parser job in an environment that has the timezone overridden to the one that you specify.  Our parser will then appropriately localize the entries found in the log.  If the specified timezone is valid for your system, it should work just fine.  Example:

As you can see, I'm in EST, but when I override the environment with PST, the date/time is reported accordingly.  This is how we run the parser if an alternate timezone is specified in the configuration.  There are several supported timezone specifications on various systems.  Google is a good place to search for valid timezone specifications.  To confirm that the timezone override is working for your remote debug logs, find a DENIED event in the log and match that up with a denial in a history report for that tag.  If things are working correctly, the time for the denial should be localized to the LM server timezone.

2. When running lmstat across ssh on a machine located in a different timezone:

If you are using lmstat against a remote server directly, the timezone should already match what your LM server timezone is.  The lmstat utility reports the times using the timezone for the machine that it runs on.  If you are using lmstat across ssh, then you will need to override the timezone in the command setting.  Example:

In this case, demo5 is in PST, so that is what is reported when I run date on it across ssh.  But I can override it to EST to get the date to reflect my timezone.  The timezone specification in the monitor administration page only affects the optional debug log parsing.  It does not affect the lmstat run.

S, for a license server running in Europe, you're probably going to want to specify something like:

for the lmstat command to get the clock to not appear incorrect with respect to the LM server clock.

To summarize, with lmstat, you must make sure that it is executed in the LM server timezone.  With debug logs, you must make sure that the parser is executed in the timezone that the debug log was generated in.

If you see high usage in your LicenseMonitor reports, we know what the situation is: you have duplicate handles in your database.

Immediate fix:
Please remove the duplicates manually with the commands like these:
% ftlm_check_db -deleteduplicates -start "20090901"
% ftlm_check_db -deleteduplicates -start "20090601"
% ftlm_check_db -deleteduplicates -start "20090301"
% ftlm_check_db -deleteduplicates -start "20090101"

Moving back in time, from September, June, march, and so on,
as far back as it makes sense.

If you use MySQL, please also use the option -keepindex.

Then regenerate the reports.

Long term fix:
If you install the latest LM patch (LM-Update-2) available from our web site,
this cleanup is automatically performed.

Explanation of duplicate checkouts:
We have been aware of the possibility of duplicate checkouts for quite some time and we have, first of all, looked for ways to eliminate them altogether.  Now we have finally realized that duplicate checkouts will always inevitably occur, so we are now adopting a strategy of:
1.  minimize occurrence of duplicates when loading the database
2.  automatic cleanup anyway

The duplicates happen because of the way LicenseMonitor detects a checkin,
which is by the absence of a previously known checkout.   This detection
is vulnerable to transient failures of lmstat.   If lmstat, for any of a thousands of reasons, fails to deliver a complete answer, LicenseMonitor concludes that the checkouts have been checked in.  At the next cycle, when lmstat succeeds, many of those checkouts  reappear and they will be logged again later on.
Duplicates are easily identified because they have the same checkout time, user, host, feature, handle.  

To fix this issue, you must set the following variable in licmon.swd/setup.tcl:

setenv VOV_HOST_HTTP_NAME your-LM-server-name

Just remember to replace "your-LM-server-name" with your actual LM server name.  This name should be equal to whatever works with your DNS.  So, if your running LM on Linux and your Windows machines can only see the machine with the full domain name, enter the full domain name.  If short names are OK in your DNS, then using the short name is fine.  After making this change, you'll need to either restart LM or do the following:

vovproject enable licmon
vovsh -x "vtk_server_setenv VOV_HOST_HTTP_NAME your-LM-server-name"
vovproject reread
vovslavemgr stop
vovslavemgr start

This is a one-time change.  New LM installations using 2009.08 Update 2 will have the fix by default.

Brian