VERIFIED SOLUTION i

How to resolve Issues when working with Date and Time fields in Portrait HQ.

There are a number of known issues that need to be considered when dealing with dates & times within Portrait Campaign Manager and Interaction Optimizer (using Portrait HQ).
The complications surround the fact that when using a date and time in a calculation, sometimes we want it to be a 'local' date and time (i.e. in the current time zone), and at other times we might want it to be meaningful across multiple time zones.
For example:
(a) If we wanted to check whether a given time fell within 'working hours', we might test the time to see whether it was between 9am and 5pm. But what we actually mean is 9 - 5 in the user's current time zone. Therefore the underlying 'greater than' and 'less than' values could not be represented as single values using universal (UTC) time.
(b) If we wanted to express a time at which an customer's insurance policy ended, we would want to express it as a UTC date time - meaning that the insurance policy would end at a particular point in time irrespective of the observer's local time zone.
This means that when we are using any comparison operators in Portrait HQ, we should try to ensure that we are either comparing local times with other local times, or we are comparing UTC times with UTC times.
You can tell whether a stated date time is using UTC by looking at its raw value. If the value has a trailing 'Z', then it means that it is being considered as UTC. When that date time value is is displayed on a computer in different time zones it will show as a different 'local' time.
When using Portrait HQ, we would recommend that you think about whether your calculations should be local- or UTC-based. If they are UTC-based, then you can use the datetime picker which will normally create the stated time as UTC, not local.
If you want to deal with 'local' times, then you should create suitably named Derived Fields using the CreateDateTime(...) function and then reference those fields in your comparisons. this is because the CreateDateTime function always creates datetime values without time zone information and is based upon the local time zone (i.e. the time zone in which the HQ server is located).
Remember that if you are struggling to make the built-in datetime operators within the HQ work for you, you can always create your own user-defined functions to suit your needs.

If you are unable to make the above recommendations work, or you want more information, please contact Support directly using the standard email address.
UPDATED:  April 18, 2017