Way to handle DST hangover in Salesforce!
Discussing here a custom solution of how one can avoid DST adjustments in Salesforce when needed.
Salesforce operates a lot of timezones on user session levels in order to handle multi-timezone business scenarios. To handle this fluently Salesforce stores all date time values in single GMT timezone at the backend level. Whenever you as a user look at a date time value in your Salesforce Org is actually a converted value for your session based on your user level timezone settings from GMT values.
In some parts of the world Daylight Saving Time (DST) timings are followed. DST is a time adjustment made to make effective use of day timing in some slots of the year in some regions of the world for some good reasons. This adjustments are like moving clocks forward/backwards by some time, on some specific days of the year.
While Salesforce handles DST and Timezone conversions very effectively on its own, there might be some critical scenarios where this DST adjustments need to be avoided.
We love using Out of Box automations to speed up the business processes however when it comes to avoiding DST effect in Salesforce there are a few problems. Let's assume you are using DATE TIME values in flows for assigning or using complex formula around it to generate future date time values and you operate in a region where DST is followed. Those assignments and formulas don't have a timezone context during execution i.e. when viewing a record those might get converted back to your own timezone + DST adjustments resulting in some values that you might not expect "IN SOME CASES".
Your organisation operates in GMT and you are generating a yearly Patient follow-up plan for one of your patient which should be on 1st of every Month at 2PM. If you try to automate this piece with any automation available will result in date time value mismatch. Observe carefully that you are creating future date time values with reference to today's time. In DST 2PM today can be 3PM in tomorrow looking from GMT timezones. However, originally Patient knows that it is 2PM on 1st of every month which is a DST in-sensitive information.
Let's see the problem in action. Here I am showing an Apex Snippet to create 12 patient follow-up events on each opportunity once its Closed-Won which will be scheduled on same time every month. Note: This Apex Code is written for demonstration purpose hence do not follow APEX coding practices like TRIGGER frameworks.
Here is out it looks.
When we assign the DateTime field a value, it instantly does the DST adjustments hence making it possible to compare the TimeDifferences with respect to First Analysis Time in same context hence making it possible to readjust again to avoid the said differences. Following are some sample changes made in the above Trigger snippet to do the same. Hence, APEX/TRIGGER is the correct way to handle DST in complex scenarios like these.