You are viewing limited content. For full access, please sign in.

Question

Question

Displaying different time zones within process/repository

asked on June 14, 2016 Show version history

We have a clients using forms all over the world and in this case within Germany. They are compiled, completed and sent on from Germany, thus UTC+2 . We here in the office operate in UTC+1 (UK time).

 

See my screenshot below. Where it would to an untrained eye appear that we have reviewed and approved a form submission before it was actually submitted. However we know this is not the case because of the time differences (1 hour difference).

 

Is there a way we can display within the 'Fields' section of the repository, where user tasks are time stamped the appropriate time zone?

For example:14.59.49 UTC+2 

 

If this is appropraite to be considered a feature request, please consider it one.

 

Thanks.

Submission Times - Time Zones.JPG
0 0

Replies

replied on June 14, 2016

The apparent conflict occurs because Web Access displays time fields in the user's timezone, but times represented in another time zone were written to a text field, which Web Access of course won't modify.  We could consider making changes to the field display.  If I understand correctly, you're talking about just annotating the display with the current time zone, not changing the value displayed, right?  Either way it seems to me that you would still want to write time zone information to the comment field, since it's the text there that is the main source of confusion.

1 0
replied on June 14, 2016

Hi Brian,

 

Understood regarding the users timezone. I think the changes to the field display based on the users timezone is what I am after. I wouldn't like to change the time the user submitted.

 

I have no issue with the time being displayed as it above because it is accurate for the user and I wouldn't want it to change when the user is accessing the repository. However I would find it massively advantageous if the time (UTC, GMT) is included in the field. 

 

Yes it would be important in the comment field as to not cause confusion. If the form goes back and forth a number of times between two different time zones, you can see how this may cause confusion among us and the clients.

 

Thanks

0 0
replied on June 14, 2016

Hi Christian, I think Forms can provide a variable called "process time zone" so that you can add that to the text field whenever it needs. I added it as a feature request

1 0
replied on January 12, 2017

Process Time Zone variable is now supported in Forms 10.2

0 0
replied on April 17, 2018

We didn't want to use processed time zones. We wanted to show the time the user signed in their time zone, but with their UTC in parens right after. So we resolved it this way:

$(document).ready(function(){

//capture timestamp
  $('.Approve').click(timestamp);

  function timestamp() {
    
    var d = new Date();
    
    var minutes = d.getMinutes();
    var hours = d.getHours();
     
    var fullYear = d.getFullYear();
    var day = d.getDate();  //returns day as 1-31
    var month = d.getMonth() + 1;  //getMonth returns month as 0-11
    var fullDate = month + "/" + day + "/" + fullYear;
    
    var tz = new Date().getTimezoneOffset();
    var tzDiff = (tz/60);
    var utc = "(UTC-";
    if (tzDiff !== 0) {
      if (tzDiff.length = 1) {
        tzDiff = '0' + tzDiff;
        tzDiff += ':00';
      }
  	  utc += tzDiff > 0 ? '+' : '';
  	  utc += tzDiff + ")";
    }    
    
    if (minutes < 10) {var minutes = "0" + minutes;}
        
    if (d.getHours() < 12) {var a = "AM";}
	else if (d.getHours() == 12) {var a = "PM";}
	else {var a = "PM"; hours = hours - 12;}

    if ($(this).hasClass('Approve')) {
       $('.approverDateTime input').attr("readonly", false);
       $('.approverDateTime input').val(fullDate + " " + hours + ":" + minutes + " " + a + " " + utc)
       $('.approverDateTime input').attr("readonly", true);
    }
  };

});  //close document.ready 

Works perfectly for our situation.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.