Testing the timer control

Some days ago I finally got around to trying out the timer control (new in Dynamics CRM 2013 Spring Release / SP1) after seeing some custom ways to use it from Magnetism Solutions and Dynamics CRM Tip of the Day. However, I experienced some issues, and this is my log, which I will keep updating as I figure this one out. I have reported this to support at Microsoft as a potential bug, and will update when I hear back from them.

Update: I reported this issue to Microsoft with the details from this post. My assigned support engineer, who was based in Spain, was able to confirm and reproduce this within 24 hours for both Norwegian and Spanish locales/formats. He was hopeful that this could appear soon in the support stream. He also confirmed that this was introduced in SP1 UR1, so if you can live with just SP1 and need the timer control, then uninstall SP1 UR1.

The issue

I expected this:

But got this in IE11:

And this in Chrome v37:


Hm. Doesn't seem right at all. NaN is something I most often see with JavaScript arithmetic and parsing operations. My mind went immediately to some sort of regional settings or defaults since this was date related.

For reference, my server has the following setup and I am using the browser on the server to test this:

  • Windows Server 2012 R2 Datacenter, English, fully updated
  • Regional formats for myself and service users in Windows is set to "Norwegian, Bokmål (Norway)" which means currency, dates and time formats, first day of week etc. might differ from a pure US setup. Location is set to Norway.
  • SQL Server Developer (64-bit), English, 11.0.5058.0
  • Server collation Danish_Norwegian_CI_AI
  • Dynamics CRM 2013 SP1 UR1 installed (update: issue introduced in SP1 UR1)
  • Norwegian MUI installed and patched to SP1 UR1
  • IE 11 and Chrome v37

A bit perplexed, I set to investigating the timer component and its internal workings, and found some interesting things.

  • The core provider file for the JS is JsProvider.ashx
  • The object definition for the timer control is called Mscrm.TimerControl
  • The NaN indicates a typically incompatible arithmetic operation, so I F12-ed and stepped through until I found the line where the text field was set to "NaNh NaNm NaNs".
  • The offending line in question looks like this: $v_2 = Math.floor((Date.parse(this.$e_0.get_failureDateTimeUtcString()) - Date.parse($v_1)) / 1e3) + this.$e_0.get_timeDifferenceInSeconds();
  • this.e_0 is actually the timer control object Mscrm.TimerControl
  • The statement this.$e_0.get_failureDateTimeUtcString() evaluates to "06.10.2014 15:00:00" and Date.parse(this.$e_0.get_failureDateTimeUtcString()) evaluates to NaN
  • If you go to JSFiddle and try to Date.parse that, in IE it will return NaN. In Chrome it will return 10th of June.

So where does this value come from? Clearly the method get_failureDateTimeUtcString() should hold some answers?

get_failureDateTimeUtcString: function () {  
        return this.$2_3;

Ok, so where does this.$2_3 come from and what does it hold? Turns out it is set with some output values from parsing an XML-string holding a lot of dates


AHA! Norwegian styled dates from the server side. This had to be it.

Reproducing and confirming

To confirm, I created a new blank organization on the server and repeated my steps to recreate the issue:

  1. Create new blank organization, English base language, collation to Danish_Norwegian_CI_AI
  2. Once provisioned, edit the phone call activity form, add a timer control (note that I did not alter any system or client settings) with failure condition for scheduledend and success for statecode with value completed
  3. Publish the form, create a new phone call with due date tomorrow and save.
  4. Result is the same, parsing errors in both IE and Chrome

Is there a workaround?

Yes! I had my application running with dedicated service accounts (domain users), so I had to set the regional settings for those users to en-US. If you are using built in accounts (network service etc.), follow this guide. No known consequences directly from that change, other than some system generated strings in the system containing dates in the en-US format.

Final notes

It is very clear from my experience and actual documentation that Date.parse can be a bit unpredictable to work with. From https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse:

A string representing an RFC2822 or ISO 8601 date (other formats may be used, but results may be unexpected).


The ECMAScript specification states: If the String does not conform to the standard format the function may fall back to any implementation–specific heuristics or implementation–specific parsing algorithm. Unrecognizable strings or dates containing illegal element values in ISO formatted strings shall cause Date.parse to return NaN.

Rant: I believe the fix here is for the product team to use only the ISO date and time stamp format (e.g. YYYY-MM-DDTHH:mm:ss.sssZ), making the component more robust and independent of browser implementations and client settings.