How do you get around the impact of UK daylight savings (BST) in date/time fields for non-UI date/time processing?

[Berto2002]

We use the Cloud node to add Change entries to the Microsoft Office Outlook calendars of some of the stakeholders.

We've just discovered the entries are starting earlier by one hour; which is not great since the calendar is supposed to tell them the agreed change start time. Silly me, I forgot that the system processes everything in UTC so an adjustment is needed in the (UK) summer months to +1hr now we are in BST.

I previously implemented the below workflow to make the adjustment. It requires admins once a year to manually re-enter a date in the Workflow to make that 1 hour adjustment if required. Logic is:

• If date is < AutumnClockChange then go the route for +1 hour for BST
  • This means after October-ish, no extra hour is added
• At the SpringClockChange we then set the expression date as the AutumClockChange for the new current year
  • This means, from March-ish to October, the extra hour is added

But the question it whether anyone else has a better idea, please, or to automate this. For example, I wish the UI daylight savings time flag was available to workflow could look-up and act accordingly...

Thanks

[Estie]

Hi @Berto2002

Would you be willing to share the contents of the nodes above?

I am trying to add a timeline entry to a request showing the date and time that a related request has been logged.  Despite using a node similar to your 'Add 1 hour to End for BST' the timeline entry still shows the time logged as an hour behind the correct time.

Any help would be appreciated.

Thanks

[Berto2002]

After detecting the date:

And we find it's BST, we do a utilities +1 to get new timestamps on start and end:

Then I format each for readability:

Update the card with the new date/time:

Now my logic is out there for all to see I wonder if someone will spot the flaws!