Expiration date is before Creation date on Survey Instances when date format is yyyy-MM-dd

About the Expiration Date field on Survey Instance records

How the value of this field is determined

The value of "Expiration Date" field on a survey instance is determined by the setting of "scheduled period" of the Survey Definition at the time this survey instance was created. For example, if "scheduled period" is "No Limit", "expiration date" will be set to the current date. If "scheduled period" is "Weekly", "expiration date" will be set to 7 days from the creation date.

Keep in mind that "expiration date" uses the date in GMT timezone. For example, if a survey instance was created in the early morning for a user in UTC timezone, the user may see "expiration date" being a day before his local date.

How this field is used

This field is used only internally for a technical purpose - it is used to determine if a survey instance should be created or if the creation would cause duplicate active survey instances.

When the system is creating a new survey instance, it checks the existing instances by their "states" and "expiration date" values in order to find out whether the creation of this instance is allowed according to the "scheduled period" setting on the survey definition.

Customers should not worry about this field and should not include it in any reporting.

Tested on Helsinki Patch 9

1. Set the glide.sys.date_format system property to yyyy-MM-dd.

2. Change the Time Zone to IST (any Asia time zone) on system settings.

3. Go to Survey Instances (asmt_assessment_instance.list).

   Note that there are instances with Expiration date before Creation date.
   
   Although the Expiration date should always be on or after Creation date regardless of the time zone, the Expiration date is before the Creation date.

   See the attached screenshot from Helsinki Patch 9.

Do not use this column for reporting. Do not compare this to the creation date for reporting purposes.