It's not strictly speaking an fme issue, you would see the same output if you performed the same expression in python. It is related to the way the computers store numbers
https://floating-point-gui.de/
An alternative to the attribute splitter is to use an AttributeCreator/AttributeManager and a ReplaceRegEx statement to replace anything after the decimal and including the decimal point with nothing
e.g.
@ReplaceRegEx(@Value(number),\.<0-9]*,"")
It's not strictly speaking an fme issue, you would see the same output if you performed the same expression in python. It is related to the way the computers store numbers
https://floating-point-gui.de/
An alternative to the attribute splitter is to use an AttributeCreator/AttributeManager and a ReplaceRegEx statement to replace anything after the decimal and including the decimal point with nothing
e.g.
@ReplaceRegEx(@Value(number),\.<0-9]*,"")
Thank you for the quick answer.
Good question. Another thing you could do is run the features through a DateTimeConverter transformer with the option set to repair overflow. Then if you do get a "60" seconds, it will be changed to the properly time.
This article explains in a bit (well, lot) more depth: https://knowledge.safe.com/questions/108860/question-of-the-week-number-rounding-errors-in-dat.html
Good question. Another thing you could do is run the features through a DateTimeConverter transformer with the option set to repair overflow. Then if you do get a "60" seconds, it will be changed to the properly time.
This article explains in a bit (well, lot) more depth: https://knowledge.safe.com/questions/108860/question-of-the-week-number-rounding-errors-in-dat.html
Deja vu - I'm sure @david_r posted this same answer on this same question earlier in the week but i don't see it now