MS Flow: ticks function behaves different if fed with a string than with a string variable containing the same string

Question

Addendum/Preface I tried a lot to process a date in the form yyyy-MM-dd coming from two columns of a custom list. I read dozens of articles about dealing with dates in flows and processing SP lists containing dates. I tried virtually every canonical method for comparing the strings, reformatting the date to UTC, reformatting it manually or converting to ticks directly. None has worked.

A short snippet of the data coming from the "evil" list, which I took from the debug view of the "get elements" action. It looks pretty normal.

{
  "@odata.etag": "\"1\"",
  "ItemInternalId": "1",
  "ID": 1,
  "Title": "a",
  "Starttag": "2020-06-01",
  "Endtag": "2020-06-24",
  "{Identifier}": "Lists%252fZeitabschnitttest%252f1_.000",
  "{IsFolder}": false,
  "{Thumbnail}": {
    "Large": null,
    "Medium": null,
    "Small": null
  },

The columns in the custom list are in standard date format supplied by the sharepoint site columns of a fresh setup sitecollection.

In my original version question described a single method, which is very close to the core of the problem, I think.

Original Question So, I deleted my last post about a complicated flow, because I have tracked down the problem to a very small detail.

It started when a date from a custom list could not be compared with a date from a calendar. I have tried many and it boils down to this:

I have a created a string variable. I fed it with a concatenation of the date from the list and a time string to make it more ISO8601ish. The variable contains then a string like:

2020-06-01T00:00:00.00001Z

while

2020-06-01

was the string part from the list and

T00:00:00.00001Z

was my addendum. When I shovel that variable into the ticks()-Function,

ticks(variables('Startdate_ref_aux'))

I get an error Message complaining about the parameter not being adherent to ISO 8601. Also the string in the error message shows only the added portion of the string, i.e. "T00:00:00.00001Z". When looking at the error message, I can see, the string in the variable is correct.

But now comes the really strange part: When I replace the variable by it's content i.e. I copy the value from the debug window, paste it into an editor and paste it back directly into the ticks() function:

ticks(2020-06-01T00:00:00.00001Z)

It works without any problems. But as it is a constant now and not a variable, my flow doesn't make sense any longer. Are there hidden characters inside that evaporate on copy and paste? And if so, how can I do that within the flow?

What else have I tried?

• I tried to compare the strings directly, which doesn't work at all. Typical error message is: The date from the list is of Type "0" (strange), while the date from the calender is of type "string" (as expected).
• I tried to convert it to ticks directly, error message complains that the given date doesn't adhere ISO 8601, because it is "".
• I tried to convert it as above, see main part of the question.
• I tried to use the more comfortable actions instead of the expressions for manipulating the variables. But I learned the "actions" doing the same as their "expression" counterparts are probably only graphical wrappers for the "expression", because the error messages are the very same ones.
• I also tried to remove non-printing characters by using substring(). But substring also refuses to work on that date, saying the received parameter is of type "0" instead of "string".
• I wanted to parse the string character by character, using split(). But the implementation of split is soooo bad, it can't work without a delimiting parameter! Hey guys at M$: Did you ever look at other languages like PERL or Python before you released that concoction of prehistoric functions?
• I tried to use trim() to remove dangerous characters at the beginning and the end of the string, but it refuses to work for the same reasons.
• So M$ implements a broken readout of SP date columns but gives no means to repair the broken strings. How's that?
• I changed the columns back to Date+Time but the problem stays the same.
• I tried to make a calculated column of the date to compile it into as a string, but sharepoint itself refuses, because of invalid data types (huh?). Making an integer calculated column from the date works, but makes little sense.

Everything boils down to this: If a date is pulled from my custom list, it throws an error at any function expecting a timestring or in most cases even a string as input. No matter, what I do with this string before, including adding characters or copying from variable to variable. When I (human) read and type the content of that variable back into another variable, all time processing functions will work without any complains.

My conclusion is, the string is poisoned by a non printing character. It even could be something evil like EOL or EOF. How else could I explain, that copy and pasting to an editor and back to the variable the incriminated string solves the problem at the time processing functions?

This would mean, that either the custom list's storage of dates is corrupt or the implementation of the flow's readout function is buggy. If so, where can I address that problem at M$?

In PERL there's the chomp() function which removes non-printing characters from a string. Does something similar exist here?

Answer 1

My problem was resolved over time. Due to some trouble with flow execution I lost some vital information about what had changed. But I have the following explanation, and I think it is very likely that this happened:

1. My second table had a single entry with one date missing. I don't know, when this entry started to exist. A missing field very likely produces a behaviour as mentioned in my question
2. Concerning the „debug“-view of my flow. I.e. the view on the past executions where you can see nearly every piece of data processed in any single execution of that flow. I did not understand how to read the information about foreach-loops properly. I saw the error-message in the box on the right side of the window but had a different pass of the loop in the flow chart selected. That probably gave me the imagination that the error had occured with an list element, which in fact had been processed without error.

Summary: The analyis of a past execution of a flow can be a little bit misleading. One has to orientate very carefully and thoroughly to prevent clashing unrelated information together. Data presented in my question may also be unrelated to the errors.

Answer 2

Yes, ticks function can be difficult to use sometimes. Instead of appending timestamp to date field on your own, you can try using:

ticks(item()?['StartDate'])

Or before using the date field directly in ticks function, you can format it using convert date time action in Power Automate.

Read below articles for more information:

1. Compare dates using conditions in Power Automate
2. Flow - Calculate Date Difference
3. Date Math in Power Automate