[Bug] String to Date/Time occasionally breaks because of ms

Dear all,

I occasionally face an issue with the string to date&Time node but can not reliably reproduce it. However, by removing the milliseconds I managed to work around it. The date and time are generated by Date&Time Widgets, converted to a table row and than, for dat filtering via Athena, converted from string to Date&Time where is actually breaks apart once a while.

Best
Mike

Hi @mw, I wonder if you are hitting the issue that the regular .SSS milliseconds mask doesn’t play nicely if the milliseconds comes in as only one or two digits, which they might sometimes do.

If you keep the milliseconds but change them in the time part of the format mask from

HH:mm[:ss[.SSS]]

to

HH:mm[:ss[.SSS][.SS][.S]]

I suspect the occasional break might go away as it will then handle all formats of milliseconds.

Just a thought. :wink:

2 Likes

Hi @takbb,

I adjusted the milliseconds to be one, two or three digits to match up the pattern ind the String to Date&Time node. I also tried to auto-match / generate the pattern within the node itself but to no prevail.

The erratic behavior is really strange. Resetting the Date&Time Widgets and choosing other date time stamps did not resolve it to my surprise. Only by doing a string manipulation upfront removing the ms unblocked the issue.

Best
Mike

Hi @mw Yes that does sound very strange.

You say it’s erratic, so does that mean that you are finding the same data would fail one time, but work on another run? I was wondering if you have a sample of timestamps that cause the failure, but I’m presuming you don’t. I just tried typing in the ones from your screenshot, but of course on mine they worked ok. I tried changing my locale to the same as yours but it still worked.
I guess that is what you are saying… that sometimes they work and sometimes they don’t… :thinking:

Hello @mw,

don’t see a bug here. String to Date&Time node’s configuration from your printscreen won’t work if you have only 2 digits for milliseconds…

Br,
Ivan

1 Like

@ipazin, I was thinking much the same except the one thing that had me intrigued is the final item in the log at the bottom, but of course I don’t know how the log ties up with the configuration at that time.

1 Like

@takbb probably configuration is changed so SS would be parsed which led to SSS not parsed…
Ivan

3 Likes