Progressive Capture Date & Time control - time zone issue?

[Luke]

Hi, 

I've had a report of an issue with times added through a progressive capture for change requests. We have a Progressive Capture using a date & time control: 

Which is later used to update the change calendar in the Business Process after approval: 

This is currently adding an hour to the times initially captured during the progressive capture. Creating a test ticket with these datetimes: 

Once the ticket is created the questions section shows the original times + 1 hour: 

After approval when the schedule update is processed it's obviously also using the adjusted times: 

I can update the schedule manually without an issue, and can also use a task process which is part of our business process to amend the time, this part using variables from the task: 

So this appears to be an issue only with the progressive capture, and as far as I know this is a new issue and I can't find any similar reports on the forum. 

I've checked my own profile's time zone which is set to GMT, as is the reporting users. I don't know if we've got a mis-match with another time zone setting somewhere, has anybody seen this before, and know how to fix or should this go to support? 

Thanks, 

Luke

[James Ainsworth]

Hi @Luke

Thanks for your post. There are some ongoing issues that have been reported here:

https://community.hornbill.com/topic/22558-invalid-date-on-find-time-beta/ 

You may want to follow that post as well for further updates.

[Luke]

Thanks @James Ainsworth - I saw that and thought it was a distinct issue based on the behaviour - good if they're the same root cause and a fix is hopefully imminent, I'll follow  

[Victor]

@Luke we tried this following the latest fix and we don't see the issue. The date/time I capture in PC is presented the same in the Questions section (same time). Is this still an issue there?

[Adam Toms]

Hi @Victor

We're having the same problem. I've just raised a test change this morning. As I believe the fix has been pushed out but as you can see from the following screen shots.

We're seeing the hour time difference. The email notification has the correct proposed time. But the Proposed Time and Scheduled Time in the change is an hour ahead.

I understand after raising an incident for this issue the fix has been pushed out but we're still seeing the same issue.

It appears our progressive capture and bpm is configured very closely to the original post above.

 

 

[Victor]

@Adam Toms how is the date appearing in the Questions section, is it also one hour off? Or it's just the change schedule?

[Luke]

Hi @Victor, 

Still an issue I'm afraid, tested just now and entered these dates/times: 

During the progressive capture the values display correctly on the RHS: 

When the ticket is actually saved the times have shifted forwards: 

Thanks, 

Luke

[Adam Toms]

Hi @Victor As per @Luke's post above I can confirm it's exactly the same for us also. You can input the correct times into the progressive capture but when it's saved the times jump and our ahead during the change request being raised. However our change notification email records the correct time, but in the body of the change it's an hour ahead. 

 

[Victor]

@Luke @Adam Toms and you capture the dates in PC using just regular custom fields (meaning they are not specifically mapped to a request custom field in PC config)?

[Adam Toms]

Hi @Victor,

This seems to be where my config differs slightly from Luke's although the symptoms of what Luke is experiencing appears to be exactly the same with ourselves.

Our Progressive Capture writes to the following location: h_proposed_start_time and h_proposed_end_time fields.

Many Thanks

Adam

[Luke]

Cheers @Adam Toms - I can create a copy of the progressive capture and add to a test service to test this if necessary but given that your use of standard fields has the same hour shift I won't bother for now. Let me know if you think this is necessary @Victor? Thanks

[Victor]

@Adam Toms @Luke ok, I will do a few tests using normal custom fields and mapped ones... I did a test last night using a single date/time field and that for me appeared fine in the Questions section... will have another look now... 

[Adam Toms]

@Victor and @Luke

Hi Both,

So this morning when i tested after the fix was pushed out I still had the issue.

I re saved and published our change progressive capture and bpm this morning, we've just had our first change come in since I did this, and the user reports no issues and things are working fine.

So I'm not sure whether it was a case that fix took a little while to get to our instance or whether re-saving and publishing our PCF and Change BPM has had the desired effect.

But if you're still having the same issues as this morning @Luke it might well be worth trying this.

Many Thanks

Adam

[Victor]

@Adam Toms @Luke there is definitely an issue here (which has a fix ready) for the dates being 1 hour off when using the new progressive capture engine. So might be this scenario for you when this issue happens. In any case the fix is getting deployed now.

[Adam Toms]

Thanks for the update @Victor much appreciated for yours and the teams efforts on this.

[Luke]

Just re-tested and all good here now, many thanks all!  

[Day Riley]

Hi @Victor,

I'm experiencing this issue too, and republishing my capture workflow and BP has not resolved it. Settings in workflow are as seen here:

 

When I'm logging a ticket, it shows correctly with the time I logged it with:

 

But when the information is being pulled through to an automated email, the time has the hour offset.

Email template:

Email received at our reception:

Please advise.

 

[Victor]

@Day Riley I'm afraid this has nothing to do with the issue in this thread. Two things: a) you store that date/time as a string (custom B is a VARCHAR field) thus it will always behave as a string and not as a date and b) you need to format that date in the template if you need there anything else but the GMT/UTC value.

For a) you can store this date/time value in a dedicated field, e.g. h_custom_21 - h_custom_25 (more info here: https://wiki.hornbill.com/index.php?title=Mapping_Fields_from_Customised_Forms) and for b) in the email template you need to have {{.datetimevariable|formatLocalTime}} which allows formatting of datetime variables using Hornbill system regional settings (system.RegionalSettings.timezone & system.RegionalSettings.dateTimeFormat), without this formatting the date time will use the DB value (UTC) (more info here: https://wiki.hornbill.com/index.php?title=Email_Templates)

For the specific issue with the display in the email only b) has relevance so you can keep that value in Custom B but if you display this value, from this field, in the UI (so not email itself, just UI), it will not have any timezone formatting.