Jump to content

Progressive Capture Date & Time control - time zone issue?


Luke

Recommended Posts

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: 

image.png.b9c897a7665a2f4af11ec4a9754eeac4.png

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

image.png.04260c7532460514176b26f56f5e83cc.png

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

image.png.5ea559e5d87539333d35062a002e9d5c.png

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

image.png.a294247435cc87d07242fa20ee6fd9de.png

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

image.png.0e6f68da1598ea0887edcf51501a6059.png

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: 

image.png.1f7e642e127ff3c8e892821f5515c56a.png

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

  • Thanks 1
Link to comment
Share on other sites

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.

 

 

Scheduled time error in change request an hour ahead.PNG

Proposed time error in body of change an hour ahead.PNG

Change Notification Email - Correct Time being displayed..PNG

Link to comment
Share on other sites

Hi @Victor

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

image.png.705f8f1faba4d59f7e438166cce4763e.png

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

image.png.726bf005b7b3a2efa5514469e365463a.png

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

image.png.8d3a61c95311264d37f8804c6bab8dd7.png

Thanks, 

Luke

  • Thanks 1
Link to comment
Share on other sites

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. 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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:image.png.b54186a0b9d71c6891971322ef019c0d.png

 

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

image.thumb.png.83e778055274d293d8c97be81126e953.png

 

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

Email template:

image.png.2083198848eacc8b76c6079d8ddcdcc7.png

Email received at our reception:

image.png.cedd7676e29cc7e8cc0aec5b1234a959.png

Please advise.

 

Link to comment
Share on other sites

@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.

 

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...