Jump to content

Time zone; converting to BST


Berto2002

Recommended Posts

I'm still struggling with how to convert the system default GMT timezone to BST when displaying in the UI. Can anyone help with what utility to use and configure to display BST?

I have the following nodes with the idea that a big banner goes across Authorised Change Requests to make it very clear when the window is open from and to.

image.png.3b7fa744b38d5e956b3456de78bb0487.png

The Cloud functions change the format into something readable. They use this approach:

image.png.efdfdc3cbdd186c93239f8c7fb748fd9.png

I then add the Notice but the result declares as GMT, the system default which is one hour out from BST giving me the risk they mis-read it and start the change at the wrong time. My users want to see BST in the Notice (obviously) because we're in the UK.

image.thumb.png.14feac16a97365145e4bd659076c8dc1.png

What is the Util and config I need to add one hour to the GMT when UK is in BST? I guess I am, looking for a "Convert Timezone" Cloud automation?

image.png.70b2ecc3c5d82f060015af009d693d50.png

Or has anyone worked out a workflow approach that checks, for example, if the UK is in Daylight savings period and if so adds one hour to the displayed time? What would I use as my external reference lookup to get that 'fact'?

I am trying to resolve this before the clocks changes because for the whole of the winter the timezone in the UK aligns with GMT so we won't see the issue!

 

Link to comment
Share on other sites

Hi Berto,

Thanks for your post.  The UI throughout Hornbill is designed to use the Timezone settings within a user's profile to present the correct time information to the user on all the date fields.  So, once we hit BST, all times that are displayed in date/time fields will be displayed in BST.  The challenge that you are having is that a request notice is not a date field, but a text field.  Building the request notice using the BPM automations is simply using information within the database to build a text string.  This string of text is not dynamic.  For example if you have some changes raised before BST kicks in, and this string for the notice is created before BST, if that change is still active after BST, the text string will not dynamically change to BST.  

Are you using the Scheduling action for these changes?  Is this the date that you are trying to show in the notice?

Link to comment
Share on other sites

I would like to mention that there is something we are looking at developing which is to allow the use of wiki markup in the request notices.  This was primarily considered to add the ability to create clickable links, but our wiki markup also includes an option that can specify a date within a string that can be dynamically updated based on the user's profile timezone.  This work hasn't been schedule yet, and it isn't clear yet if it will support what you are looking to do, but it may.

For more on wiki markup click here

  • Like 2
Link to comment
Share on other sites

Hi James. I understand how if it's a text field then it will show as GMT; because the system is tracking everything in that zone.

Yes, the information displayed in the Notice is picked-out from the "Scheduled Start" and "Scheduled End" dates of the "Get Request Information" node; and then passed into the Cloud Automation format it to be user-friendly. Me seeing that as derived from a Data/Time field naively assumed the UI would then interpret that to the user in the Notice in their timezeone. 

It looks like the product is currently unable to display a reliable date and time in the Notices because of this design anomaly; hence why I was asking if there are any ways to work around this in workflow: to convert the GMT system output to BST during daylight savings only.

So the challenge is whether there a way to code "last Sunday in March" and "last Sunday in October" into a Customer Expression so the workflow can either add or not add one hour!?

In the UK the clocks go forward 1 hour at 1am on the last Sunday in March, and back 1 hour at 2am on the last Sunday in October. [When do the clocks change? - GOV.UK (www.gov.uk)]

Link to comment
Share on other sites

@Berto2002 we pass to a local server where we run code to allow this transformation to happen then pass back into a custom field within the request.

But I'm sure that a cloud based server would work just as well, it's just a case of telling the Cloud Automation node where to point.

Link to comment
Share on other sites

Getting "last Sunday in March" and "last Sunday in October" is not quite possible. The alternative is to check for the specific date. I understand the date for daylight saving is different every year but that's yearly so updating the workflow once a year is not that cumbersome, I think... even so I expect the wiki date format in notices to be implemented soon(ish) so I don't expect a yearly workflow update to go on for too long... 

Anyway, if one wants to implement this check for BST based on the specific date this can be done as follows:

1. Have a Cloud Automation Utility node to retrieve current timestamp. Like this:

image.png

Operator param is mandatory so it needs to be set but for our purpose it can have any value, we are not actually adding or subtracting any value here because:

2. All other params will be set to ignore. The Starting Timestamp as ignore will use current date/time and the other values set to ignore means we are not altering this current date/time in any form for the Timestamp output param value.

3. In the workflow continue with a decision node that will check in the value for Timestamp output param (returned by the Cloud Automation node) is less than, let's say 2021-11-01 00:00:00. If yes then it means the current date/time falls within BST, if the value is greater than 2021-11-01 00:00:00 then it means the current date/time falls is outside BST. Example for how the expression looks that checks if the date/time is within BST:

image.png

 

Edited by Victor
Incorrect values for the expression
Link to comment
Share on other sites

@James Ainsworth and @Victor. This seems like a great candidate for a Cloud Automation enhancement doesn't it? Either a new Cloud Automation Utility or something to simply check to "Get User Timezone" to enable a conversion. In the meantime, I will go with the manual re-configuration Victor has suggested as it's in my area of control and get that in and tested before the end of the month.

Link to comment
Share on other sites

That's a good point. So it would need to be a Cloud Automation to output the date in a specified timezone. For MOST Hornbill customers, they would operate a standard timezone for the whole organisation.

Link to comment
Share on other sites

3 minutes ago, Berto2002 said:

For MOST Hornbill customers, they would operate a standard timezone for the whole organisation.

I can see why you'd think that, but it's simply not correct. Even if we only take our US customers they have 6 time zones to deal with even if they don't deal outside the US - some have 2 time zones without leaving their State.

Link to comment
Share on other sites

1 minute ago, Berto2002 said:

For MOST Hornbill customers, they would operate a standard timezone for the whole organisation.

Not quite, it is actually the opposite :) ... Most of our customers, while many located having HQ in UK have users located all over the globe. Might be the case that their Hornbill instance is set to a specific timezone but the users will have different one based on where are they located.

Regardless, the Cloud Automation would not work. Once you format that date in any shape, it will remain like this until another node re-formats it... The solution, in my view, is to have the date/time formatted in the UI based on the timezone of the user that uses that UI. This allows the system to hold a set date (GMT/UTC) while displaying it differently based on user preference.

The solution or workaround would work for your specific requirement here and now since you need that BST conversion for all your users and it will only be feasible in this scenario.

Link to comment
Share on other sites

I can see the conundrums here. All I can do is express that a requirement to allow times to be displayed in Notices  - picking-up the user timezones like other fields in the UI - would be useful. I guess what you guys do with that information is up to you now.

Link to comment
Share on other sites

Each one is using a different input because the format change nodes do not alter time. The ones down the No Match route use the raw scheduled dates/times from the Get Information node and the ones down the BST route use the outputs from the "+1 hour" nodes. I don't know a way to specify one such node can accept either of two inputs.

Link to comment
Share on other sites

Are these nodes using the same function/operation? If yes, no need for separate formats after decision ends... if they use the same operation then they would output the same param, just with different value... and from what I see the format is just changing the way it appears, like using the day name... so it does not matter what value it gets (and is all about value afterall) it will format it regardless...

image.png

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...