Hi Mei and others.

I have confirmed that changing datepickerlongyearphpuserdate is a very bad idea. The easiest place to see the problem is in dynamic audiences, but there are other places that are most likely also affected, which include (but is likely not limited to) due dates in goals, learning plans and objectives.

The problem is that it displays on the page in one format and parses user input using a different one. If you choose the date 1 August 2016 then when you load the page you will see 08/01/2016. Save this date and next time you load the page, it will show 01/08/2016. This will fail if you use the date 25 January because 25 is not a valid month, or if you choose a new format such as "May 5 2016" because "May" is not a valid number from 1 to 31. So if you've changed the format, it's just a coincidence that it hasn't failed already.

I had a quick look at what would happen if datepickerlongyearparseformat was changed to complement datepickerlongyearphpuserdate, but I was unsuccessful in getting this to work.

So I strongly urge you to leave these two strings as they were originally. As I said in my last post, if you want to change the output in the messages, the code relating to program message date variable substitution should be changed to use some other string key which can be safely customised.

Nathan