5

When I query a Task's ActivityDate in Apex accessed using JavaScript Remoting, I receive a date that is different from the date displayed in the Salesforce interface.

The query below (with a generic Account Id) results in 2012-09-11 for a specific Task, but the date is displayed as 9/12/2012 when viewing the Task in the Salesforce interface. It seems all ActivityDate fields for all Tasks are different by a day.

SELECT Id, AccountId, Account.Name, Priority, Status, Subject, ActivityDate, Type, 
Owner.Name, Owner.Id, What.Name, WhatId, WhoId, Who.Name, LastModifiedDate FROM Task 
WHERE AccountId IN ('001000000000000')

The time-zone of the User accessing Salesforce through the interface and through SOQL is the same - (GMT-05:00) Central Daylight Time (America/Chicago).

Does anyone have advice on how I can account for this in Apex or JavaScript (without Visualforce; I'm using Remote Actions)?

  • If you change the users time-zone to GMT-0 does the issue go away? It is almost certainly related to their timezone offset and Salesforce automatically adjusting the dates for display. – Daniel Ballinger Sep 25 '12 at 21:07
  • The issue does not go away when I change the User's timezone to GMT-0, but I think you're right in that it's almost certainly related to the timezone offset. – Matt K Sep 25 '12 at 21:10
  • Another possibility is that the issue is in the JavaScript/Remoting handling of the Date. If you use a SOQL explorer tool do the values look correct before being returned for remoting? Or try writing the values out to the Debug log to see if they get changed when passed through the remoting. – Daniel Ballinger Sep 25 '12 at 21:16
  • Why would the time zone impact a non-DateTime field? Regardless of timezone wouldn't the visible date and the SoQL date be the same since there's no reference to time? – Salesforce Wizard Sep 25 '12 at 21:17
  • The date is the same when using the SQOL Explorer tool and comparing against the date displayed in the Salesforce interface. The issue occurs when the values are returned through remoting. – Matt K Sep 25 '12 at 21:26
7

Javascript remoting returns dates in milliseconds since epoch. The javascript date constructor interprets the milliseconds since epoch as a date time in your local time zone, thus the discrepancy. Use the following function to correct the date:

var ONE_MINUTE = 60000;
...
function epochToDate(jsRemotingResult) {
  var epochDate = new Date(jsRemotingResult);
  return new Date(epochDate.getTime() + epochDate.getTimezoneOffset() * ONE_MINUTE);
}
  • This also worked for my use case, and should help in any instance in which the dates returned via Javascript remoting do not also have a time. This is because dates with no time are turned to milliseconds since epoch by assuming the time as 00:00.000. So, if your dates include times (like 17:00), you would probably want JavaScript to construct the local time zone version (e.g. 12:00 in that example) without adjusting for the timezone offset. – Andrew Patton Dec 5 '13 at 22:32
  • 2
    Also, I would clarify that the ONE_HOUR variable is actually ONE_MINUTE as milliseconds (1000 [mil/sec] * 60 [sec/min] = 60000 [mil/min]). Which also illustrates that getTimezoneOffset() actually returns the offset in minutes, not hours. – Andrew Patton Dec 5 '13 at 22:37
0

Ok - the following is a guess. I haven't had time to check it out, but it could be a good directly for further research.

The ActivityDate field in Salesforce is a Date field, not DateTime - so it should be independent of timezone.

However, the Javascript Date object is equivalent to DateTime. So the question is - how is it being created from the Date object?

Let's assume for a moment that the date Sept 11, 2012 is marshalled into a Java date object of Sept 11, 2012, 0:0:0 GMT (which would be quite reasonable, for example, if a millisecond count was being used in the transfer). Well, if you then view the local equivalent of that date anywhere in the world except for the GMT timezone, I expect you would get a date on the previous day - since GMT always gets the date first.

If I'm right, the getUTC... functions on the retrieved object should give you the correct date.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.