Best practice forum (Archived)

该论坛讨论已删除

该论坛帖子的内容已被删除，无法再访问。

Hi Pingtao,

The date format is set by the language pack, and the locale settings. To change the date format, without changing the language pack, you would have to identify every date string and edit it according for every language used on your site.

regards,

George.

永久链接 | 显示父帖子 | 回复

该论坛帖子的内容已被删除，无法再访问。

永久链接 | 显示父帖子 | 回复

Hi Pingtao,

These are set by the language pack (I checked by switching) I'm afraid its a combination of locale and language settings, the only solution is to find the appropriate strings and manually editing.

regards,

George.

永久链接 | 显示父帖子 | 回复

该论坛帖子的内容已被删除，无法再访问。

永久链接 | 显示父帖子 | 回复

Hi Pingtao.

The normal way to change the format on the page is to change the language string. This can be done by going into Site administration -> Language -> Language customisation, choose a language, choosing a component and "Show string". Find the string key and enter some date format string. Use the following page to guide you to choosing the format you want:

http://www.w3schools.com/php/func_date_strftime.asp

Save the changes and check out the result. You'll need to repeat for every language that you have installed. Note that this will change the format everywhere that string key is used.

However, in this case, because the key is "datepickerlongyearphpuserdate", it's not that simple. If you customise this string, it'll probably break date pickers in forms. It might work if you also changed "datepickerlongyearparseformat" to match it, but it would require investigation and testing, so I'm not confident in suggesting that.

An alternative is to change the lang string key which is used when formatting the dates in that particular bit of code. In the file you were looking at (totara/program/program_message.class.php), a few lines up, you'll see:

$formatdate = get_string('datepickerlongyearphpuserdate', 'totara_core');

You could change "datepickerlongyearphpuserdate" and/or "totara_core" to some other language string which matches the format that you want, e.g. "strftimedate" and "langconfig" (to see all the options, follow the steps above and select the "langconfig" language component). This will change the formatting only in this specific part of the code (just message variable replacement in program messages), for users with any selected language.

I think that that piece of code shouldn't be using "datepickerlongyearphpuserdate", that it should already be using one of the other lang strings. I'll file a bug to investigate and have it changed (assuming my logic is correct). It'll likely still end up being formatted "05/08/16" but at least then you could customise the format safely as described at the start.

Nathan

(Edited by George Angus - original submission Wednesday, 24 August 2016, 2:54 PM)

(Edited by George Angus - original submission Wednesday, 24 August 2016, 3:10 PM)

永久链接 | 显示父帖子 | 回复

Thanks George/Nathan.

We have this same requirement to have letters instead of numbers in %duedate%. Something like 05/08/16 can be May for North America and August for Austraila and UK. Although it's by language settings but it still confuses users from time to time. I changed the datepickerlongyearphpuserdate from %d/%m/%Y to %d-%b-%Y or %d-%B-%Y without changing datepickerlongyearparseformat and that seems to format the date very well in message. I am just not sure what the impact on other components are and hoping to know where datepickerlongyearphpuserdate is exactly used so we can test the change more thoroughly. Ideally I would like to avoid code changes if possible.

Cheers,
Mei

永久链接 | 显示父帖子 | 回复

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

永久链接 | 显示父帖子 | 回复