DateTime(String) does not understand the new NetServer dateformatting

Hi,

a couple of weeks ago Marek blogged about Changes in 9.1R3: Date, Time and DateTime in Archive Providers and today we saw the first real consequence of this in a script at a customer. 

Seems like the DateTime(String) method in Service doesn't understand the new format, so script that has been running fine for years now breaks. Basically, NetServer changed but CRMScript didn't.

Here is a simplified script that shows the problem. I've tried to make it as simple as possible so that anyone can copy-paste it to test.

#setLanguageLevel 3;


NSArchiveAgent agent;
String[] columns = String("registeredDate").split(",");
NSArchiveListItem[] items = agent.GetArchiveListByColumns2("FindContact","registeredDate", "", "contactId > 0", "contact", 1, 10);

for (Integer i = 0; i < items.length(); i++) {
  print(items[i].GetColumnData().get("registeredDate") + " => ");
  DateTime date = DateTime(items[i].GetColumnData().get("registeredDate"));
  printLine(date.toString());
}

The code above behaves differently from 9.1 SR3 than it did before.

Another way of showing the issue is

printLine("Using DT: "  + DateTime("[DT:12/31/2020 23:59:59]").toString()); //Previous format
printLine("Using D:  " + DateTime("[D:12/31/2020 23:59:59]").toString());   //Format used from v9.1 SR3+, which DateTime doesn't understand

I believe the issue also happens for datestrings that are returned from UserdefinedFields, so it's not just when working with archives.

As a temporary workaround we need to use this on the string that is passed to the DateTime method.

.substitute("[D:", "[DT:")

I see someone kind-of reported it in this bug (https://community.superoffice.com/en/product-releases/bugs-wishes/product-issue/?bid=75879) but it was rejected. I disagree with the rejection.

I belive the only correct fix is that SuperOffice fixes the CRMScript DateTime(String) method to also parse the new dateformat correctly.

Comments?

RE: DateTime(String) does not understand the new NetServer dateformatting

Hello,

We always use the decodeDBValue function on fields from CRM before using the value (by passing it into the DateTime constructor for example).

Looks like the decodeDBValue was updated, since it works fine:

#setLanguageLevel 3;

printLine(decodeDBValue("[DT:12/31/2020 23:59:59]"));
printLine(decodeDBValue("[D:12/31/2020 23:59:59]"));

printLine("");

printLine(DateTime(decodeDBValue("[DT:12/31/2020 23:59:59]")).toString());
printLine(DateTime(decodeDBValue("[D:12/31/2020 23:59:59]")).toString());

printLine("");

printLine(DateTime("[DT:12/31/2020 23:59:59]").toString());
printLine(DateTime("[D:12/31/2020 23:59:59]").toString());

printLine("");

printLine("Using DT: "  + DateTime("[DT:12/31/2020 23:59:59]").toString()); //Previous format
printLine("Using D:  " + DateTime("[D:12/31/2020 23:59:59]").toString());   //Format used from v9.1 SR3+, which DateTime doesn't understand

printLine("");

printLine("Using DT: "  + DateTime(decodeDBValue("[DT:12/31/2020 23:59:59]")).toString()); //Previous format
printLine("Using D:  " + DateTime(decodeDBValue("[D:12/31/2020 23:59:59]")).toString());   //Format used from v9.1 SR3+, which DateTime doesn't understand


By: David Hollegien 29 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

Ok, so that is another type of workaround then. Since DateTime(String) doesn't accept the new format that NetServer spits out, I still feel like DateTime(String) should be fixed to parse the new format.

By: Frode Lillerud 29 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

Hi,

We try our best to not brake stuff and will look into solutions to rectify this without braking something else ;)

By: Michel Krohn-Dale 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

Thank you Michel :)

I believe the problem is fixed when this code asserts successfully:

#setLanguageLevel 3;

String newFormat = "[D:12/31/2020 23:59:58]";

DateTime dt = DateTime(newFormat);
assert(dt.getYear() == 2020);
assert(dt.getMonth() == 12);
assert(dt.getMDay() == 31);
assert(dt.getTime().getHour() == 23);
assert(dt.getTime().getMin() == 59);
assert(dt.getTime().getSec() == 58);

I took a look to see if there were any other methods with similar problem, but couldn't see any. "DateTime DateTime(String)" seems to be the only problematic one.

The "Date Date(String)" method seems to work correctly. It didn't handle the NetServer dateformat in earlier versions, but it does in 9, so that is a good thing.

By: Frode Lillerud 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

That sounds a bit strange.

DateTime has had support for "DT:" for a long time, and Date has had support for "D:" for a long time.

DT: denotes that the data value in the following string is a DateTime, and D denotes that the data value in the following string is a Date.

So there has been no changes to this for a long time (I think this is from 7.x something, maybe 7.0).

But I think there might be a misunderstanding here? 
There are no changes in the format of a SO Date (D:) and DateTime (DT:). As far as I understand, there is a change in what datatype the archives now returns. 
They return (D:) if the underlying data is a Date. Earlier they returned "DT" no matter what. Or am I missing something here?

 

By: Stian Andre Olsen 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

Hi Stian,

the issue is that NetServer now returns "[D:" for datetimes, not "[DT:" as it used to. And if we pass "[D:" into CRMScript-DateTime-method, it doesn't accept it.

"[DT:" is no longer a thing in NetServer.

The DateTime class in CRMScript needs to be changed so that it understands that "[D:" is used for datetimes now.

From Mareks post this section is relevant (where I believe he implicitly calls CRMScript single-minded 😀)

By: Frode Lillerud 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

If you have access to a SuperOffice version prior to 9.1 SR3, and you run the first code in the first post, you'll see this:

If you run the same code in a version after 9.1 SR3, you get this:

The code is the same, but the result is different.

Note that the CRMScript doesn't have any explicit notion of the [D: vs [DT format. It just asks NetServer for a DateTime-column, then tries to parse it into a DateTime and fails.

By: Frode Lillerud 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

I had a chat with Marek, and I now understand how the archive works.

When they return "D", it actually tells the GUI to only display is as a Date, but it contains correct time values in the time part as well.

I do not think "DT" has been removed from NetServer, and his snippet in the blog indicates that it still is there:

I am pretty sure that for example the dot-syntax provider still uses DT, so I will not remove the support for DT from the DateTime class.

But will fix so that it understands D:
Will also fix so that the Date class understands DT, as it does not do that today.

By: Stian Andre Olsen 30 Oct 2020

RE: DateTime(String) does not understand the new NetServer dateformatting

Great, adding support for "[D:" should be enough 😀 No need to remove support for "[DT:"

By: Frode Lillerud 30 Oct 2020