To get the current time from your computer in UTC you have to use the Windows function TzSpecificLocalTimeToSystemTime.

I have examples in my BCrypt and CryptoAPI examples.

https://www.topwizprogramming.com/freecode_bcrypt.html

Thanks again ,  this is useful stuff and is of great help. I appreciate all your help with this!

Mark

Whatever works "best" = most robust in your environment!
You own the support burden; I don't ;-)

Anyways, TEST your desired time zone to ensure it is viable setup.
Rather fail fast than delay testing and find out you went down the wrong rabbit whole.

And yes, audit trail requires you can somehow sort log entries in correct chronological order.
TEST: Hit some test button simultaneously on two PCs to compare timestamp
You may be surprised how much two PCs may differ.

// EVENT = cb_Test.Clicked
MessageBox( 'Local Clock', &
   String(Today(), 'YYYY.MM.DD') + '~r~n' + &
   String(Now(),   'HH:MM:SS.ffffff')

I often end up choosing DB server as "clock source" to have sufficiently trustworthy clock.
I just fired below SELECT at my local SQL Any 17 to gauge the different clock sources. 

SELECT Test.Data, Test.Value
FROM  (SELECT 1 "#", 'GetDate' "Data", CAST(GETDATE() AS VARCHAR) "Value"
 UNION SELECT 2, 'Now',                CAST(NOW() AS VARCHAR)
 UNION SELECT 3, 'Current Stamp',      CAST(CURRENT TIMESTAMP AS VARCHAR)
 UNION SELECT 4, 'UTC Stamp',          CAST(CURRENT UTC TIMESTAMP AS VARCHAR)
 UNION SELECT 5, 'TimeZoneAdjustment', CONNECTION_PROPERTY('TimeZoneAdjustment')) Test
ORDER BY Test."#";

Data looked like below (same value! and TimeZoneAdjust matches current time zone in Windows O/S config)

Enjoy, /Michael

Michael, thank you for the detailed reply.  I feared we might have to add code.

 My other thought is to stay with standard timestamps but correct the date/time using the timezone offset of the primary database server, rather than that of the remote server.  This way all the audit trail is relative to the primary server and makes some sense.  This is primarily for auditing data, created timestamp , last modified timestamp etc.. This is not quite as elegant as your solution but probably safer and quicker to implement.

MARK

You're right. PowerScript (and the DataWindow engine) has neither concept of UTC nor time zones. So this requires extra code!

For SQL Anywhere pick DocCommentXchange and search for "TimeZoneAdjustment". When I read docs that connection property seems to be able to adjust datetime values to client's local time zone even though database internally uses different time zone (EX: UTC).

I advise to use UTC as much as possible when you do date/time calculations and comparisons. It is practically impossible to handle all daylight savings differences and all time zones unless you follow algorithm like:

1. Convert each local zone INPUT value => UTC value
2. Perform calculations, comparisons; etc.
3. Convert each UTC OUTPUT value => local zone

It may even be multiple different INPUT zones and OUTPUT zones. Pure UTC calculation will be free from any daylight savings adjustments.

HTH /Michael