The screenshot on the right shows the configuration for a Restriction that takes this criterion into account:

• Within a Field restriction, the left side per Property projection refers to the 'Password expiry date' field. This field is of the 'Date with time' type.
  
  

• On the right side of the Field restriction, the Relative date with time value resolver is used to define the cut-off date for the comparison by the 'End of current month' Type.
  
  

• The Matchers used here is a Compare with for which a '<' condition has been selected.
  
  ►NOTE◄ A Time Zone has not been specified here. Therefore, the default time zone applicable in the context of the session is taken into account for the delimitation of the month. The comparison is effectively made using the 'UTC milliseconds', so that the time zone of the expiration date can also have an influence on the display of users.

►NOTE◄ Corresponding restrictions can also be used to define a search for an Import profile in Lobster_data. The XML structure on the right shows how easy it is to access a predefined 'Relative date' (in this example: END_THIS_MONTH) via the DateTimeValue object (here as the value element of a Field restriction) within a Search.

<?xml version="1.0" encoding="UTF-8"?>
<core:PropertySearch xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:core="CORESYSTEM">
   <core:PropertyProjection property="passwordExpiryDate"/>
   <compareType>&lt;</compareType>
   <value type="END_THIS_MONTH" xsi:type="core:DateTimeValue"/>
</core:PropertySearch>

The screenshot on the right shows the configuration for a Restriction that takes this criterion into account:

• Within a Field restriction, the left side refers to the 'Password expiry date' field by Property projection. This field is of the 'Date with time' type.
  
  

• On the right side of the Field restriction, the Relative date with time value resolver with the 'Custom' Type is used, since there is no predefined time 'in 14 days'. The start of the 15th day after today (in the 'Europe/Berlin' Time Zone) is calculated as the Custom time based on the current system time. This value is no longer accepted by the criterion in connection with the '<' comparison.
  
  

• The Matchers used here is a Compare with for which a '<' condition has been selected.

►NOTE◄ Here, a Time Zone is explicitly specified for the calculation. If the 'Password expiry date' was entered in a different time zone, the field projection still provides the decisive 'UTC milliseconds'.

Event handling responds to the event 'Copy' (see Common action event) as a Triggering event. With this trigger, event handling becomes active immediately when a user executes the 'Copy' ribbon command. Therefore, the data object created as a copy can be initialized before the user gets access to it via the already opened data input form.

The Validating rule uses Check type to ensure that actions are performed only if the copied entity is a guest user account.

A set value event action is executed here as an Action on passed rule:

• On the left, an Object property value resolver defines the 'Valid to' (validTo) field as the target of the value assignment.
  
  

• On the right, two instances of the Relative date with time value resolver are concatenated to schedule the expiration of the validity of the copied account:
  
  

  • The first Relative date with time value resolver initially determines the 'Begin of next day' based on the current system time (see Type parameter), but refers to the Time Zone 'Europe/Kiev'.
    
    

  • The Relative date with time value resolver concatenated below uses the 'Custom' Type to add the offset of 36 hours (+36) to the previous value.

►NOTE◄ Instead of concatenation, it is possible to use only a Relative date with time value resolver that concatenates the expression for 'Begin of next day' in the Custom time parameter (see Date time type) with the expression for the offset:

0h 0m 0s 0S +1d +36H ... or the equivalent result ...
0h 0m 0s 0S +2d +12H ... or equally equivalent ...
12h 0m 0s 0S +2d

►NOTE◄ The explicitly assigned time zone 'Europe/Kiev' in the upper right corner is taken over for the calculation and the finally assigned value, because the concatenated Relative date with time value resolver does not use an explicit selection for the Time Zone parameter.

With the adaptation of the existing configuration shown on the right the time zone 'Europe/Kiev' is used for the calculation, but in the 'Valid to' (validTo) field the time zone already entered in the copied guest user account is retained:

• On the left and on the right, the 'Date value' (dateValue) field is accessed by concatenation with an Object property value resolver.
  
  

• As a result, the assignment affects only the millisecond component of the 'Date with time' data object, while its time zone is ignored on the right and kept unchanged on the left.