Jump to content

Resolution time on Resolved emails incorrect before clocks went back, also showing a Z at the end of the string?


Adrian Simpkins
 Share

Recommended Posts

Hi All,

We have noticed that prior to the clocks going back the time a request was resolved the date stamp in the outgoing Resolved email was an hour out of sync - now the clocks have moved back this issue is not occurring and showing the same time/date stamp, but I wanted to highlight this in case it happens again when we move clocks forward in the spring.


Also, we note that at the end of this time stamp there is a 'z' being displayed - can this be removed at all?

Many thanks!

Timeline date stamp: 

image.png.aa3aaceb06fb6f7ff5cf4a1afac571af.png

Outgoing email date stamp:

 

image.png.927e04a53d04c825219b75eb1df15243.png

Link to comment
Share on other sites

Hi Nasim

Yes all generated from templates - however I was unaware of the formatlocaltime addition - I will review and insert this where required into our templates.

Do you also see the Z at the end of the date string as well or is that just something we are seeing here?

 

Thanks!

Link to comment
Share on other sites

We had the time difference and Z in our emails until we added the |formatLocalTime bit into the template

Although don't understand why you are seeing this now....its been like this for months (22nd June) for us.

Nasim

  • Like 1
Link to comment
Share on other sites

This is the reply I got from Victor - yes we should read the wiki :-)

Dear Nasim

On 11/06 we deployed a platform update which contains the following:

Added email template modifier called formatLocalTime to support formatting of dateTime columns/variables using system-defined regional settings. This system modifier uses these system settings (system.regionalSettings.timezone and system.regionalSettings.dateTimeFormat) for formatting.

This was implemented to address an issue whereby date/time fields in email template were incorrectly formatting the date and time based on analyst date/time format and timzeone settings. These date/times should have used the system setting, not an analyst setting.

The date/time fields in email templates can now be formatted using the above modifier. This is documented on the wiki as follows:

{{.datetimevariable|formatLocalTime}} = Allows formatting of date/time variables using system regional settings (system.RegionalSettings.timezone & system.RegionalSettings.dateTimeFormat), without this formatting the date/time will use the DB value (UTC).

https://wiki.hornbill.com/index.php/Email_Templates

Kind Regards,
Victor Szekler
Senior Technical Support Specialist

Customer Support Team

Hornbill logo

  • Like 1
Link to comment
Share on other sites

Hi Nasim

I have updated the templates to include the formatLocalTime against the time / date stamp variables, but still showing the wrong format / z at the end. I have read through the Wiki again and it refers to 2 settings to configure, and both of these appear configured so unsure why the formatting is still not as expected. The 2 Images show how the 2 settings are configured, and the 3rd shows the email with the format - as you can see the email is defaulting to YYYY-MM-DD HH:MM:SS even though it is set to DD-MM-YYYY HH:MM

just to confirm my personal date time settings are set to the same format DD-MM-YYYY HH:MM

Thanks !

227857917_timezonesetting1.png.3867b850d439ee0dd71efb9655a1b201.png

1095320062_timezonesetting2.png.790d69cc8f3673c210a169022310e84f.png

image.png.b1e0bfc1e8bd71766c7ee0bae082a79e.png

image.png

Link to comment
Share on other sites

This looks fine - so not sure why the DB date/times are showing - are they still an hour out?

Have a look at the actual templates (as the settings look good).

See an example we have used:

image.png.a20b18f12047915f0c241a1125dfee04.png

 

If nothing obvious - then I would raise a request with Hornbill to check.

Nasim

  • Like 1
Link to comment
Share on other sites

To close this thread off, the issue was that the Editor had injected formatting within the delimiters of the variable, so when parsed the placeholder was not recognised.

If you come across this issue you can correct it by using Source Mode to remove unwanted HTML markup.

For example:
 

{{.H_respondby</span><span style="display:inline !important; float; none; background-color: rgb(238, 238, 238); color: rgb(51, 51, 51); ">|formatLocalTime}}

should be simply:
 

{{.H_respondby|formatLocalTime}}

 

  • Like 1
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...