Jump to content

Time on emails showing as GMT not BST


Recommended Posts

Hi folks

When requests are logged via hornbill's "I want to book a minute taker" the time selected is not being reflected in the automated emails, appearing to not have taken daylight saving time into consideration, as it is always an hour before.

Just to confirm it is just the emails being effected, the actual request details show the right time

Basically we have date conversion nodes in the Minute Taking BPM and it seems to be taking an hour off. 

Is this a system setting / wokflow config we've missed or is it a bug?  Please help

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

Hi @Stuart Torres-Catmur

When you say it is only the email date value that is an hour off, but the request date value is correct could you clarify the following:

On the request if the customer has input a date / time in a Progressive Capture field then the value should be visible in the Questions section on the request.

If you have then used the Integration Call Node (iBridge > Utility > Date Formatter) to convert this value, are you then writing this value to a Request Custom Field in the request details section of the request?

If so could you compare the value in the questions section on the request and the value in the custom field in the request details section (or forward a screen shot) as typically it will be a value in a custom field which will then he added as a variable in the email template which is sent out.

Finally could you also share a screen shot of your Integration Call (iBridge > Utility > Date Formatter) node configuration to see if we can spot anything

Thanks

Steve

Link to comment
Share on other sites

Hi @Stuart Torres-Catmur having looked at this i can replicate the issue you are experiencing.

There is a workaround option you could try.

1. In your progressive capture form where you have the date / time field if you Map this question to one of the new datetime specific custom fields - h_custom_21 being one of them

image.png

2. You can remove the date formatter node 

3. On the request the value in the Questions section should be displayed correctly

image.png

4. The value in the h_custom_21 field will still display incorrectly in the UI (offset by one hour)

5. If you include the h_custom_21 field in your email template this will display the correct value to your end user

image.png

We are looking into the behaviour but this workaround should allow your correct date / time value to be displayed in the questions section on the request and in the email which goes out to the customer. The only minor additional consideration is that the date / time output will include the seconds value.

Steve

 

Link to comment
Share on other sites

Guest jpopoff

Hello,

I suppose this is similar to the issue reported last week since the change of time.

We are also affected in our change process, and the incorrect timing is currently showing on email, task generated by the tool which are being assigned to our senior management for approval.

Jmarc

 

Link to comment
Share on other sites

  • 2 weeks later...
On ‎29‎/‎03‎/‎2018 at 8:01 AM, Steven Boardman said:

We are looking into the behaviour

Hi @Steven Boardman, any news on this?  The workaround does work but I have instances where I have more than 5 date/time fields in a progressive capture so as there are only 5 new date/time custom fields available I'm having to still use custom fields A-T for some of them and therefore have the issue with the date/time displaying on auto-emails, 1 hour before what is entered in the custom field on the PC.  Help!

Sam 

Link to comment
Share on other sites

Hi @Victor, we are now at Build 1221 but still have the issue with the date/time showing different to what was entered in the PC.  The error only occurs when the custom field is A-T and not if we use one of the new date/time format one's (21-25).

Attached is an email extract showing the issue.  The first five dates shown use custom fields 21-25 so are correct but as there are only 5 date/time custom fields I used custom L for the sixth entry which is displayed incorrectly (see highlighted).  This should show 06/05/2018 00:00 but shows 30-04-2018 23:00.  This isn't even one hour before anymore so not sure what's going on?

The service request is SR00034560 in case you need it.

Thanks

Sam

Capture.PNG

Link to comment
Share on other sites

9 minutes ago, SJEaton said:

I used custom L for the sixth entry which is displayed incorrectly (see highlighted)

It is actually displayed correctly. Custom L is not a date/time field is a varchar field, which means any value stored in this field will be a string and not be converted.

 

14 minutes ago, SJEaton said:

This should show 06/05/2018 00:00 but shows 30-04-2018 23:00

Can you explain a bit why it should display that value?

Link to comment
Share on other sites

I ran out of date/time custom fields to use so had to use another custom field (I don't now what varchar means??)

The PC is an overtime claim form and therefore 06/05/2018 00:00 was selected from the date/time picker as a claim date/time (custom field L).  I then have h_custom_l as the variable in the email but it has displayed as 30-04-2018 23:00.  It must be something to do with me using custom L but can you advise what we could use instead if we run out of date/time fields?

Sam

Link to comment
Share on other sites

Just now, SJEaton said:

(I don't know what varchar means??)

It basically means the values stored in this field will be a simple text (string) and will not be converted as Hornbill does not know if the value stored there is just a text or it means something else (like a date) that could be possibly converted.

 

2 minutes ago, SJEaton said:

The PC is an overtime claim form and therefore 06/05/2018 00:00 was selected from the date/time picker as a claim date/time (custom field L).  I then have h_custom_l as the variable in the email but it has displayed as 30-04-2018 23:00.

I'll have a look at the request example you mentioned and get back to you.

Link to comment
Share on other sites

  • 3 weeks later...

@SJEaton ok, I think I finally found out what is happening here... on both SR00034560 and SR00038346 there is no issue actually but there might be some misunderstandings: You said that you capture the sixth entry for date/time in Custom L. That is correct, according to "WF Services Overtime Form" PCF definition. However, in your process ("WF Services Overtime Claim"),  you are overwriting the value in this field. This happens in the first "Convert Date" node and the following "Update Custom Fields" node. In the "Convert Date" node you convert this variable: &[global["flowcode"]["answer4"]]. This variable represents the fourth answer from the "wfsovertimeclaim" custom form of the PCF (based on the "previous Get wfsovertimeclaim form" process node). Answer 4 on this form is not the sixth date/time entry, is actually the first date/time entry (Claim 1). This has the value of "01/05/2018 00:00:00". Because of BST conversion in the UI, this date/time value becomes "30/04/2018 23:00:00" and this is how you end up with this value in Custom L field.

Suggestions: If you indeed want to pick up the sixth entry from progressive capture "overtime claim" form then in the "Convert Date" node you need the &[global["flowcode"]["answer24"]] variable (so is 24 not 4)

Screenshots:

image.png 

image.png

 

 

Link to comment
Share on other sites

@SJEaton well this is interesting :D ...  right, try and type in the variable then directly then (forget about the picker) for now ... so instead of &[global["flowcode"]["answer4"]] type in &[global["flowcode"]["answer24"]] ... see how this works :) 

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
 Share


×
×
  • Create New...