It looks like it is parsing the Date to a String twice.
Consider this adding this test method to GenericScimResourceObjectTest.java:
@Test
public void testDates() throws ScimException {
String path1 = "path1";
Date date1 = new Date(9482087542L);
String date1String = "1970-04-20T17:54:47.542Z";
//date1 and date1String are equivalent
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
Assert.assertEquals(df.format(date1),date1String);
String expected = "{\n" +
" \"path1\" : \"1970-04-20T17:54:47.542Z\"\n" +
"}";
GenericScimResource gsr = new GenericScimResource();
gsr.replaceValue(path1, date1String);
Assert.assertEquals(gsr.toString(),expected);
//replacing a Date value should be equivalent to replacing date as String value
gsr.replaceValue(path1, date1);
Assert.assertEquals(gsr.toString(),expected);
}
As written, this test will fail. It seems replaceValue(String path,Date value) generates this:
{
"path1" : "\"1970-04-20T17:54:47.542Z\""
}
instead of this:
{
"path1" : "1970-04-20T17:54:47.542Z"
}
The workaround of course, is to just avoid the variants of replaceValue() in GenericScimResource that deal with java.util.Date.
It looks like it is parsing the Date to a String twice.
Consider this adding this test method to GenericScimResourceObjectTest.java:
As written, this test will fail. It seems replaceValue(String path,Date value) generates this:
instead of this:
The workaround of course, is to just avoid the variants of replaceValue() in GenericScimResource that deal with java.util.Date.