Hmmm... It appears it nulls any input that couldn't be converted. I'm not sure if that's the "right" way to do it. @mark2atsafe can you weigh in on this?

A quick workaround would be to use the StringSearcher before the DateTimeConverter to check whether it matches the expected input format.

@redgeographics thank for answering. Im' stil new to fme so i dont really know how to use the StringSearcher. Can you give me some example on how to use it?

Have it search in the attribute that holds your date and set the regular expression to

\d{4}(0r1-9]|1Â012])(0s1-9]|t12]p0-9]|3<01])

Do keep in mind that this will only match the correct date format: so 4 digits for the year, then 2 (which can not be over 12) for the month and 2 (which can not be over 31) for the day. It will not check wether it's actually a valid date. If you put in 20190231 it will say that's ok.

I've set up an example workspace, run it with prompting for user parameters and then enter a date in YYYYMMDD format (or not) and see how it gets processed.

date_example.fmw

I think that in FME2019 the transformer has an option to ignore nulls. However, the date input format has to be set correctly to match the data. If not - or a feature doesn't match - then the feature will exit the rejected port with date set to null. If it happens to every feature then it's likely the input format is not correct.

My workaround:

1. Create a "backup" copy of the date/time attribute
2. Push through the DateTimeConverer
3. Copy back the "backup" to the original attrib on the rejected port.