Emerson Exchange 365

I just recently had to address this, so here goes.
It depends where you need to execute the decision making.
If you need the control logic to act upon the result, then create logic in a control module calc block to
1. convert the UTC string to epoch time UTC
2. convert the local time to epoch time UTC
3. compare the two values as epoch time. Epoch time is an integer in seconds since a prescribed date in the past (1970 or 1972 I forget for DeltaV specifically ). Always do calculations against UTC, and preferably in an unambiguous format such as a serial date stamp or integer.

Here is the logic:

(* This will convert a UTC string time to Local String Time and evaluate against current time.

NOTE: If the UTC offset for the specified date/time
is different than the current offset, then the incorrect local time will show.
NOTE: All INT32 suffix parameters must be 32 unsigned bit integers, except for OFFSET which must be signed,
all STR suffixed parameters are strings.
UTC-TIME-IN-STR : The input UTC zoned string
LOC-TIME-OUT-STR: The output locally zoned string
*)

(*Convert Input UTC Time String to Epoch UTC*)
'^/EPOCH-TIME-INT32.CV' := STR_TO_TIME('^/UTC-TIME-IN-STR.CV');

(* Get Current Epoch UTC Offset *)

'^/UTC-NOW-INT32.CV' := TIME('$time_format:UTC');
'^/LOC-NOW-INT32.CV' := TIME('$time_format:Local');
'^/OFFSET-INT32.CV' := '^/LOC-NOW-INT32.CV' - '^/UTC-NOW-INT32.CV' ;

(*Evaluate difference between input time and now in epoch UTC*)
IF (('^/EPOCH-TIME-INT32.CV' - '^/UTC-NOW-INT32.CV' ) > 0) THEN
(* The Input Time is after Now - Add Action Here*)
ELSE
(* The Input Time is before Now - Add Action Here*)
ENDIF;

(*Calculate Output Epoch Local Time based on current Offset*)

'^/EPOCH-LOC-INT32.CV' := '^/EPOCH-TIME-INT32.CV' + '^/OFFSET-INT32.CV';

(*Convert the Output String Local Time. This can be displayed*)

'^/LOC-TIME-OUT-STR.CV' := TIME_TO_STR("%A",'^/EPOCH-LOC-INT32.CV');

It is important to note that conversion of a time stamp to or from local that is in a different DST shift than current will always be incorrect. So it is 2019-10-24T14:50:00 UTC / 2019-10-24T10:50:00 EDT now, and if I input 2019-11-05T00:00:00, the calculated local EST time will be off by one hour since we are ending DST here on the East Coast of the US on November 3. This will not affect the logical evaluation of input UTC vs. Now since we use epoch UTC for both values and there is no shift concerns there, but if you want to display the converted time, then there is that caveat. .

In the unlikely event you need to execute this logic in the HMI only (for example the operator enters the value and the system immediately evaluates, but the decision making is left with the operator), there is VB scripting to do this which is a bit more complicated, but can prevent loading the controller unnecessarily.