Jelleh
Jelleh

Reputation: 116

Why does qUnit's assert.equal think these 2 strings are different in IE?

I am working with some qUnit tests written by another developer and am having some trouble understanding why a particular test in IE is failing.

There is a function that can convert a number of differently formatted string dates into a UTC date and it seems to function correctly. However, I am having some issues with testing it in IE.

In order to test it I am taking the return of the function (which is a number rather than a standard formatted date), creating a new date from it and then using JavaScript's toLocaleString() function to get a string I can compare to another string I created. An example of the test is below; minus the call to the function, I have replaced the call to the function with the output I get from it.

var expectedResult = "11/11/2000 12:56:00";
var actualResult = new Date(973947360000).toLocaleString():
assert.equal(expectedResult, actualResult);

This fails but I cannot see why, I am not using a deepEqual() and the types are the same anyway (I have debugged and checked). I think it may be down to IE's encoding but am not sure of 1, how to ascertain this is the case and 2, get around it/effectively test it. It is worth noting that this test passes fine in FF and Chrome, though Chrome appends "PM" to the end of the date.

Any help would be greatly appreciated.

Below is a snapshot of the output from IE.

qUnit output difference

Upvotes: 5

Views: 384

Answers (1)

Jelleh
Jelleh

Reputation: 116

Seeing as no one else is coming forward with an explanation I am going to simply submit my workaround as an answer.

It would appear that .toLocaleString() in Internet Explorer is encoding the space between the 2 dates differently to how a string initialised by JavaScript does. Using the following code replaces the .toLocaleString() space and allows an effective evaluation of the equality of the 2 values.

.replace(/[^ -~]/g, '');

As I only need to know that the displayed date has the same value as the input date this is acceptable.

Upvotes: 2

Related Questions