function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
GoForceGoGoForceGo 

Why is this assert failing?

 

         System.Debug('Lead Date is ' + Leads[0].Last_Visit_Date__c);
         System.Debug('Task Date is ' + Tasks[0].Last_Visit_Date__c );
         System.ASSERT(Tasks[0].Last_Visit_Date__c == Leads[0].Last_Visit_Date__c); 



In the debug log, I see that the two date/times are equal.

 

09:14:49.039 (5039665000)|USER_DEBUG|[39]|DEBUG|Lead Date is 2011-06-13 16:14:45
09:14:49.039 (5039832000)|USER_DEBUG|[40]|DEBUG|Task Date is 2011-06-13 16:14:45
09:14:49.040 (5040367000)|EXCEPTION_THROWN|[46]|System.AssertException: Assertion Failed
09:14:49.040 (5040601000)|FATAL_ERROR|System.AssertException: Assertion Failed

 

I have excluded other code, but this is in test method. I have a trigger  on lead which updates the task associated with that lead and sets the last visit date.

In the test method, I set the last visit date on Lead and update the lead. I query the database for all tasks associated with that lead and do the assert


 

 

Best Answer chosen by Admin (Salesforce Developers) 
Soul AgesSoul Ages

I think here's the answer: http://www.salesforce.com/us/developer/docs/api/Content/primitive_data_types.htm

[...] Regular dateTime fields are full timestamps with a precision of one second. [...]

 

So, the precision of the dateTime field is one second while the dateTime object has a millisecond.

 

Maybe truncating the value to one second precision before comparing?

 

 

All Answers

Soul AgesSoul Ages

That's a weird one. Did you try using the getTime to compare the Long representation of each value?

GoForceGoGoForceGo

Good Idea.


The long times are different....I don't know why that would be....

 

10:52:20.602 (7602915000)|USER_DEBUG|[39]|DEBUG|Lead Date is 2011-06-13 17:52:15 Long time is 1307987535554
10:52:20.603 (7603123000)|USER_DEBUG|[40]|DEBUG|Task Date is 2011-06-13 17:52:15 Long time is 1307987535000

 


Soul AgesSoul Ages

Are you assigning the same value or using Now()? The Now() may be different in one call than another. The difference between both values is less than a second, so it doesn't show in the formatted string. If you need them both to be the same value, the code should update one from the other.

GoForceGoGoForceGo

I do assign one value from the other in the trigger, not system.now. It appears that millseconds are dropped when storing or querying from the database. When querying from database, the last 3 digits of getTime always seem to be zero.

 

See code below.

 

 

Leads[0].Last_Visit_Date__c = System.Now();
update lead;
Tasks[0] = [select Last_Visit_Date__c from Task where Id = :Tasks[0].id];
//without the lead query, the assert fails.
//when you query the database the assert works, seems like milliseconds are dropped.
Leads[0] = [select Last_Visit_Date__c from Lead where id = :Leads[0].id];
System.ASSERT(Tasks[0].Last_Visit_Date__c == Leads[0].Last_Visit_Date__c);

 

11:20:23.715 (5715860000)|USER_DEBUG|[48]|DEBUG|Lead Date is 2011-06-13 18:20:18 Long time is 1307989218000
11:20:23.716 (5716235000)|USER_DEBUG|[49]|DEBUG|Task Date is 2011-06-13 18:20:18 Long time is 1307989218000

 

 

 

 

 

 

 

 

 

 

 

 

Soul AgesSoul Ages

I think here's the answer: http://www.salesforce.com/us/developer/docs/api/Content/primitive_data_types.htm

[...] Regular dateTime fields are full timestamps with a precision of one second. [...]

 

So, the precision of the dateTime field is one second while the dateTime object has a millisecond.

 

Maybe truncating the value to one second precision before comparing?

 

 

This was selected as the best answer
GoForceGoGoForceGo

Yes, seems like precision is second in some places, but milliseconds in other places. System.Now() returns in milliseconds.

SFDC should consider this a bug and make it consistent across.