Supporting Multiple Timezones - MobileCaddy DevelopersMobileCaddy Developers

It’s a common scenario for users of your apps to be working across different timezones. This in itself can cause complications, but knowing how HTML elements, Angular and Salesforce cater for dates, time and timezones can greatly reduce issues.

This article is for the developers of mobile apps, and assumes a knowledge of JavaScript

Background

Dates within Salesforce are stored in an internal date format, and are stored in UTC (Coordinated Universal Time) format. This Salesforce Date data type does not have a “time” part.

JavaScript has it’s own Date object – which does have a “time” part – and again is in UTC form, and is stored as the number of milliseconds since 1 January, 1970 UTC.

When handling dates, MobileCaddy does this as transparently as possible, and passes the UTC timestamp between the client and the platform.

The Gotchas

This may all seem straight forward, until we introduce the default behaviour of Browsers and JavaScript, and timezones.

JavaScript and Browsers will, by default handle dates according to the user’s local timezone, and here is where it gets messy.

Displaying Dates

Say you have a Date stored in Salesforce of 19th April 2017. When this date is pulled down to the mobile device it is converted into a JavaScript Date Object, and now has the value 1492560000000. This is still 19th April 2017, but it also tells us that this has a time part of “00:00:00”. If I were to output my date using the dev console, I might see something like this, if I were in Los Angeles.


var myDate = new Date(1492560000000);
 
myDate;
Tue Apr 18 2017 17:00:00 GMT-0700 (PDT)

var myDate = new Date(1492560000000);

myDate;

Tue Apr 18 2017 17:00:00 GMT-0700 (PDT)

The date is being shown in local time, and in the dev console I get some information about the timezone too.

Now let’s look what might happen if we were to use this date in our Ionic (Angular) app. Here’s a snippet from a template;


 <p>{{event.Start_Date__c | date}}</p>

{{event.Start_Date__c | date}}

This would, probably quite unexpectedly, output the date as Apr 18, 2017. Again, this is in local time, but because we’re rendering just the date part, the information about the real date according to UTC, has been lost.

One approach to getting this working as we want is to create a custom filter. This can be useful if you want to ensure a consistent rendering of dates across the application. This can be achieved by adding the following into the ~/www/js/controllers/controllers.module.js file (which is part the MobileCaddy shell applications), and we have add the code below just after the mcSyncSpinner directive.

Note, the filter proceeding example gives us a specific output format, and this might not be exactly as you require, but should give you a good starting point.


/**
 * Takes a date object and returns in a readable UTC string form.
 * @param  {Date}
 * @return {string}
 */
.filter('dateUTCStr', function() {
  return function(x) {
 
    if (typeof(x) != "undefined" && typeof(x) !== null) {
      var myDate = new Date(x);
      var monthNames = ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];
 
      if (myDate.getUTCFullYear() == 1970 && myDate.getUTCHours() === 0 && myDate.getUTCMinutes() === 0) {
        return "-";
      } else if (myDate.getUTCFullYear() == 2099) {
        return "No date set";
      } else {
        var day = myDate.getUTCDate();
        var monthIndex = myDate.getUTCMonth();
        var year = myDate.getUTCFullYear();
        return day + ' ' + monthNames[monthIndex] + ' ' + year;
      }
    } else {
      return "";
    }
  };
})

/**

* Takes a date object and returns in a readable UTC string form.

* @param {Date}

* @return {string}

.filter('dateUTCStr', function() {

return function(x) {

if (typeof(x) != "undefined" && typeof(x) !== null) {

var myDate = new Date(x);

var monthNames = ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];

if (myDate.getUTCFullYear() == 1970 && myDate.getUTCHours() === 0 && myDate.getUTCMinutes() === 0) {

return "-";

} else if (myDate.getUTCFullYear() == 2099) {

return "No date set";

} else {

var day = myDate.getUTCDate();

var monthIndex = myDate.getUTCMonth();

var year = myDate.getUTCFullYear();

return day + ' ' + monthNames[monthIndex] + ' ' + year;

}

} else {

return "";

}

};

})

This directive can be used, like this


<p>{{event.Start_Date__c | dateUTCStr}}</p>

{{event.Start_Date__c | dateUTCStr}}

With the directive and template written as above, the output should gives us date strings such as “18 Apr 2017”

Inputting Dates

Inputting dates suffers the same “default behavior gotchas”, if using an html date input. If you use it without paying attention to timezones the browser and JavaScript will by default create a date in local format, and this will again give you an incorrect “time” part to the date.

Angular comes with an “ng-model-options” directive for date inputs though, and the use of this should mean you can create dates and not suffer the pain of timezones. Here’s an example of it in action


<label>
  <span class="input-label">My Date</span>
  <input type="date"
    ng-model="vm.event.Start_Date__c"
    ng-model-options="{ timezone: 'UTC' }"/>
</label>

<label>

My Date

<input type="date"

ng-model="vm.event.Start_Date__c"

ng-model-options="{ timezone: 'UTC' }"/>

</label>

Background

The Gotchas

Displaying Dates

Inputting Dates

Further Reading

Want to get building?