I agree that this is unexpected behavior, I was able to reproduce it as well. Even the AttributeRounder set to round down with 0 decimals gave the wrong result.

Unless someone comes up with a good workaround, consider forwarding the case to Safe support, pointing back to this thread.

Isn't this a floating point issue? The following in python returns 20200220015760.0

Looks like you're right:

and

Someone told me about floating point issues a while back :-)

https://knowledge.safe.com/questions/3538/attribute-rounder-0145.html

To avoid floating point issues, try using the StringReplacer to simply remove any decimal point and everything that follows at the end of the value:

I should definitely follow this guy... ;-)

Thanks everyone. Looks like the string functions may be better for this.

I'll file this with the devs. I know it's expected from the computing point of view, but I'm sure we must be able to come up with a fix for this - at least in the AttributeRounder. Using a direct function might be a different matter.

So I made this my question-of-the-week.

While writing that it occurred to me that perhaps you could just use the round() function instead of int(), and then put the data through a DateTimeConverter with Repair Overflow turned on.

If you just want valid datetimes, rounded to the nearest second (up or down), that would be the way to go I think.

But if you absolutely want them rounded down/truncated, then the StringReplacer is the better solution.