Alex,

This is another addendum to what I wrote earlier.

Unfortunately, the routine I supplied is not 100% accurate. It is 99.98% accurate, however. Here's the problem.

One hour, each year, occurs twice. This is during the period of transition from Daylight Savings Time to Standard Time. For example, 1:01 AM occurred twice on October 31 this year. It happened once during Daylight Savings and once during Standard Time.

It's easy to think that you can simply compare the biases as returned by a call to GetTimeZoneInformation. Unfortunately, this doesn't work.

My original post deals with any date/time, including those which have past. As I've mentioned, it's only 99.988% effective.

You can, however, record the current date/time without this concern. The following snippet adjusts the date/time value to UTC time, and takes into account the problem described above.

FUNCTION CurrentUTC
LOCAL ltdatetime, lctimezone
ltdatetime = DATETIME()
SET PROCEDURE TO CON_INT ADDITIVE
oInteger = CREATEOBJECT("ConvertInt")
RELEASE PROCEDURE CON_INT
DECLARE INTEGER GetTimeZoneInformation IN Win32API;
  STRING @lpTimeZoneInformation
lctimezone = REPLICATE(CHR(0), 172)
= GetTimeZoneInformation(@lctimezone)
ltdatetime = ltdatetime + (oInteger.StringToInteger(LEFT(lctimezone, 4), .T.) * 60)
RETURN ltdatetime

The above adjusts the date/time based on the current (when the function is called) bias.