Handling Time Zone Discrepancies in Workflow Date Processing for Global Users
Hello!
I’m working on a workflow in Nintex Automation Cloud that manages two calendars: one for the "Start Date" and another for the "End Date." The platform is configured to the Colombia time zone (GMT-5), but it’s used by people in various countries.
I’ve identified an issue related to time zone differences. For example, an employee in Europe requests the dates of November 4 and 5, but when the request is processed in the workflow, the dates show up as November 5 and 6.
Upon reviewing the workflow, I found that the dates are currently formatted using UTC+12:00 (Asia/Kamchatka). This could be causing the date shift when handling requests from different time zones.
Question:
Which UTC time zone should I use in the workflow to avoid this kind of error when users from different regions submit dates?
Are there best practices or alternatives for handling time zone differences effectively in workflows that cater to a global user base, ensuring that submitted dates remain consistent regardless of the user’s location?
Thank you
Page 1 / 1
Hi everyone,
To provide a bit more context, when an employee enters start and end dates, the data we receive sometimes doesn't align with what's been entered. This discrepancy affects our calculation of the days taken by the employee, including conditions related to weekends and holidays.
If anyone has any ideas on how we could solve this issue, it would be greatly appreciated.
Employee Form
Instance Details
@Yhaizley RV - have you tried to convert the Start Date and End Date values to UTC (i.e. time-zone neutral) before writing it to SharePoint? I would start by trying to do the conversion in the submit form as a form variable, but if that is not possible, I do the conversion inside the workflow itself.
Hello! Thank you for your response.
I’ll try submitting it from the form first, but I’m not entirely sure how to do it.
When using the format date function in the workflow, it doesn't seem to work.
Hey @Yhaizley RV,
Something to be aware of if not already familiar. When you use a date-only control, the date selected does not include the full 23:59 hrs of that day, only midnight 00:00. It is because the date pickers assume UTC (YYYY-MM-DDT00:00:00Z). I have fallen foul of this when using ‘on or before’ (less than or equals) functions for date values entered in a form - especially setting up date ranges for filtering work. If you want to include the whole day, you will need to either use date/time controls, or use the ‘before’ (less than) function and choose the date for the next day.
Example using DD/MM/YYY format:
Date range from 01/01/2024 to 31/01/2024, to get all items in that last day, up to 23:59, you have to use the less than function on the ‘to’ date and set that date to 01/02/2024, otherwise you will only get items up to 30/01/2024.
The ‘from’ date using ‘on or after’ (greater than or equals), is not affected, as it starts at midnight that morning, so will capture everything that day.
Just one worth remembering.
Hello!
Thank you for the information! It’s very useful; I’ll keep it in mind. @SmashedMonkey
Additionally, I’d like to mention that the time difference issue was resolved by setting the time zone in this section. For some reason, I had overlooked this part, but during a call with Nintex Support, we realized it.
All that needed to be done was to set the time zone. This way, if someone uses the form from another country with a significant time difference compared to Colombia, the dates will ignore the browser's time and default to the selected time zone
Hi i faced the same problem except the system always offset a day from my user input. Therefore it is always a -1 day different on what was saved on my MySQL versus what was input on the form.
I have tried various method (did not work at all) like
Setting time zone on all the datetime field input, mine was (GMT +8)
Setting all datetime field to default time zone used by Nintex by disabling everything
It always caused some form inaccuracy one way of another. So after round of testing i notice the only way to tackle the ‘glitch’ was to identify if the datetime field on the submission form or task form are amended fields. Where user can potentially update.
If yes, before adding the date data to your database, you have to -1 day (in your case) , +1 day (in my case) to ensure the date save is accurate (Connector : Operations - Add time to date). The datetime field on my form are set to Nintex default (all option unselected) as regional user will be utilizing the same form, so it does not make sense to configure my time zone to the form.
Additional bonus tips would be, if the field does not require time input, the data type of your field on database should only be ‘date’ and not ‘datetime’.
