Hello,Sven and Developers especially...
I can reproduce this issue as well and referred it to our developers. I will inform you here as soon as I have more information.
Would it actually be better that PlanMaker parse the incoming syntax, and "allow" for a wider range of input, then place the results accordingly.That is, allow for input being, for example:
mm/dd/yy (more used in U.S. and North America)
mm/dd/yyyy (more used in U.S. and North America)
dd/mm/yy (more used in Euro ??)
dd/mm/yyyy (more used in Euro ??)Optionally, but likely a bit more complex to do in the code parsing, allow for:
Month Day, Year (Example: January 20, 2011)
Day Month, Year (Example: 20 January 20, 2011)
Both the above, or at least thee first thought, would both give users "their way" to do it, and
stop more than a handful of PlanMaker "error calling", etc ??
PlanMaker would not be able to guess whether 11/10 is the 11th of November or the 10th of November. For this, it has to rely on the country settings in the Windows control panel. But as for the other issue about the written-out month name, the bug has been fixed and won't occur anymore in the next service pack.