^Y, ^M, ^D
...whereas the DateFormatter uses:
%Y, %M, %D
Has anyone else noticed? Does it bother you? Do you think they should be the same prefix (probably
?
I just noticed that the TimeStamper uses the format:?
?
Page 1 / 1
As long as the syntax is recorded in the help, I for one don't particularly mind.
Given that the format is also recorded in the defaults in the transformer is also helpful enough to make it easier to forgive the discrepency in my opinion.
Standardisation is always preferred but I'd say other things definitely take priority in this case ^_^
I'm a stickler for consistency where possible, but pedantry can tip some over the edge. So agreed, in the grand scheme it doesn't matter but when standing in front of a room full of new users, it can help the general message if things are consistent across the board. For example, why should the ListSorter allow you to sort using a Parameter, but the Sorter does not?
I had not noticed, and I would prefer the % since everywhere else that is the time string format convention that I come across in Python. I find dates the hardest field to parse and translate correctly. The decimal places on times have to be stripped off for the parser to work and dates before 1900 are not supported so there are lots of things that could be better with date handling. I usually resort to strings. Sqlite converts dates to an epoch of seconds if the field is numeric which is not recognised.
I had noticed the difference and would prefer one of the two would be used.
It is easier to explain during training if it is consistent in all transformers.
% is used commonly in some languages (e.g. Python, Tcl), but I don't know any language that uses ^.
Although available syntax is documented clearly in the help doc, it might be better if % could also be used in the TimeStamper.
I'd like to see consistency and have a slight preference for %
We're going to be looking hard at dates over the next months and we can finally say goodbye to the ^ then. Historical note -- the ^ was introduced (by me) close to 20 years ago because old FME used to attach significance to % for "transfer variables". (If you know what those are, you're a true FME Old Timer). I'm good with saying goodbye.
I had not noticed, and I would prefer the % since everywhere else that is the time string format convention that I come across in Python. I find dates the hardest field to parse and translate correctly. The decimal places on times have to be stripped off for the parser to work and dates before 1900 are not supported so there are lots of things that could be better with date handling. I usually resort to strings. Sqlite converts dates to an epoch of seconds if the field is numeric which is not recognised.
We're going to be looking hard at dates over the next months and we can finally say goodbye to the ^ then. Historical note -- the ^ was introduced (by me) close to 20 years ago because old FME used to attach significance to % for "transfer variables". (If you know what those are, you're a true FME Old Timer). I'm good with saying goodbye.
We're going to be looking hard at dates over the next months and we can finally say goodbye to the ^ then. Historical note -- the ^ was introduced (by me) close to 20 years ago because old FME used to attach significance to % for "transfer variables". (If you know what those are, you're a true FME Old Timer). I'm good with saying goodbye.
Yeah, that rings a bell :)
We're going to be looking hard at dates over the next months and we can finally say goodbye to the ^ then. Historical note -- the ^ was introduced (by me) close to 20 years ago because old FME used to attach significance to % for "transfer variables". (If you know what those are, you're a true FME Old Timer). I'm good with saying goodbye.
That's a goot news!