Update ticket's due by date with value from custom field

Hi@roland.ng 
Good day!

Are you using Liquid Filters to ensure that the Custom Date Field in your Ticket Form is transformed to an acceptable API format? If I had to hazard a guess, this transformation is what is playing foul. 

Ex:

If you use this Liquid Filter described above to transform the content, then the API call with use your Helpdesk’s default timezone while using the date field. 
Ensure your helpdesk’s timezone is also set as expected. 

References for Date Fields:

Input for date fields is expected to be in one of the following formats:

YYYY-MM-DD
YYYY-MM-DDTHH:MM
YYYY-MM-DDTHH:MMZ
YYYY-MM-DDTHH:MM:SS
YYYY-MM-DDTHH:MM:SSZ
YYYY-MM-DDTHH:MM:SS±hh:mm
YYYY-MM-DDTHH:MM:SS±hh
YYYY-MM-DDTHH:MM:SS±hhmm

If the time zone information is not present, it will be assumed to be in UTC.
( some valid datefields : 2016-02-15T21:16:25Z, 2012-12-24T12:56:15+05:30, 2010-03-23T12:00 )
For more details on date format: ISO 8601

Thank you for reaching out. Based on your explanation, it seems like the issue might be related to how the Workflow Automator processes time zone conversions when updating the Due By and First Response By fields. Since your custom datetime field correctly reflects GMT +8 (Hong Kong), but the updated ticket fields shift by 8 hours, the system might be interpreting the value in UTC before applying the time zone offset again.

To resolve this, you may want to:

1. Check if the API request is automatically converting the datetime to UTC before updating the ticket fields.

2. Explicitly set the time zone when updating the Due By field using the API.

3. Verify whether the Workflow Automator or the placeholder processing logic adjusts time zones separately.

Since accurate deadline tracking is crucial for processes like Annual return filing in Hong Kong, ensuring the correct time zone handling will help prevent discrepancies in compliance-related tasks. Let us know if you need further assistance!