Date User Parameter becomes a varchar with different format

In 2026.1, Safe seems to have tightened the date parsing

I recently posted about Is function DateTimeNow() in >2026 no longer supported.... in favour of CurrentDateTime? ISO_8601 durations | Community where I can’t work out the date type user paramaters

Another unexpected datetime issue I’ve encountered, is upgrading DateTimeStamper now enforces a default ISO output. Most of my downstream processing to these highly used transformer… expected it as FME date output… so I have alot of broken workspaces should I upgrade transformers

Now that you mentioned it: I’ve ran into that one as well. I write out logfiles quite a lot (for keeping track of changes made by nightly processes) and I always use a DateTimeStamper with the date to Fanout my logfiles to yyyymmdd_<logfile_name>. That suddenly got messed up indeed…

But you’d think that something like that would then be enforced everywhere, and apparently it isn’t.

​@s.jager 

FME 2026.1 moved to ISO 8601 datetimes across the board, so new Date Only user parameters now store as 2026-01-01 instead of the old FME format 20260101. It's logged under FMEFORM-13030. The DateTimeStamper surprise you and j.botterill both hit ties back to a related open item, FMEFORM-37767, about bulk transformer upgrades silently defaulting to the new format.

That said, by our own records existing parameters in existing workspaces shouldn't change format unless the parameter itself is recreated, so what you're seeing, on an older workspace with no parameter recreation, looks like it may be going further than intended. That's worth us digging into rather than just filing under "expected."

Possible fix/workaround: add a DateTimeConverter right after you reference the parameter, to force it back to FME format so it matches your existing DateTimeConverter attribute. That should get your Tester comparison working again without touching anything else.

One thing that would help us dig further: did you resave the workspace itself in 2026.1.2, separate from upgrading the DateTimeConverter and Tester individually? If not, I'd like to look into this more, feel free to open a support ticket with your build number so we can check.

Thanks for flagging it, let us know how it goes!

OK. Not sure if I’m happy with that, since I now always have to change the setting from ISO to FME, but that is what it is. I basically never use ISO formatted dates or datetimes, unless it’s specifically required by whatever format I’m writing to - and then I won’t change it until right before writing the data out. And especially for fanning out the FME format for dates is extremely useful. 

I do not remember, and it is too long ago that I would be able to check. All I remember is that it suddenly did not work anymore as expected, but I’m not using a versioning system - so I have no way of going back a month or more to see what the exact changes were that I made when I discovered it. Since upgrading usually requires a lot of intensive testing (to avoid surprises like this!), I usually try to avoid it as much as I can - but that does not mean that I didn’t copy and paste the setup from an old workspace into a new one for example.

I posted about this, particularly at the end of this article about Updating deprecated articles ahead of releases and informing recommended actions e.g. DateTime function now ISO8605 | Community

Good question. Must’ve missed it earlier, but I wholeheartedly agree.