Non-US dateformat, jquery datepicker and core c5

Permalink 2 users found helpful
I recently altered my site.php to set the dateformat to UK.

define('DATE_APP_GENERIC_MDY', 'd/m/Y');
define('DATE_APP_GENERIC_MDYT_FULL', 'd/m/Y H:i:s');
define('DATE_APP_GENERIC_MDYT', 'd/m/Y H:i:s');

However on entering public date of 10/01/2011 (tenth of Jan) the datepicker shows that it thinks the date is 10 Jan 2011 which is right. Save the properties and then go back to the properties. Date has now changed to 01/10/2011 which is the US format of the date so it is first October, which is wrong.

It seems core c5 saves the date in the wrong format.

I referred to a previous post ( which alludes to the bug being known and fixed in svn but on looking at the source of 5.4.1 it hasn't been changed.

I tried the temp solution outlined in that post but it doesn't fix the issue.

I've written about a similar issue around the Extended Form Addon and the dev says he is looking at it.

From my point of view it seems the non-US dateformat isn't exactly consistently supported in Core C5.

Am I wrong?

View Replies:
stevegibbings replied on at Permalink Reply

Really no one has a view on this? Can the Core team please explain their view and what the issues are for non-default date formats? Is it that the dates as used in the Dashboard can't be altered or down to individual Addon devs to handle things if they want?

I was sur[rised there isn't an explanation of this in the documentation so at least non-US site devs know what the situation is to make a choice. The DATE_APP... settings aren't even explain, requires a search in the forums.

If C5 is to make a bigger UK impact, which I'd like to see, then this is something that is going to need to be solved or at least explained.

madeforspace replied on at Permalink Reply
Date format is definitely an issue that would be good to addressed if possible.
Apart from a 'hear hear' there is not much more that I can add.
msglueck replied on at Permalink Reply
bump. any news on that?

I was able to change the initial dateformat displayed by a datepicker by changing the GENERIC_DATEFORMAT in app.php. But as soon as I select another date it reverts back to US date format. ;(
stevegibbings replied on at Permalink Reply
Sorry I stopped using C5 because ofd these issues.
andrew replied on at Permalink Reply
Sorry if we only provided 80% of a solution with the original date constants.

I've just checked in an addition to github; You can now define another constant in config/site.php that is DATE_APP_DATE_PICKER, which controls the jQuery UI datepicker dateFormat property. Documentation on that property is here:

Practically speaking, for your issues, I would do the following:

1. Define your date constants as this:

define('DATE_APP_GENERIC_MDY', 'd-m-Y');
define('DATE_APP_GENERIC_MDYT_FULL', 'd-m-Y H:i:s');
define('DATE_APP_GENERIC_MDYT', 'd-m-Y H:i:s');

I think part of the problem you were having is that d/m/Y is pretty ambiguous, and PHP's strtotime (which we use extensively) assumes this is an American date. (See the note on this page: So I've changed the constants to use dashes, which will parse better.

2. Add this line to your site.php, and make sure you're using the latest concrete5 from github (or copy the latest change set from github out to your site:)

define('DATE_APP_DATE_PICKER', 'dd-mm-yy');

This will make jQuery UI datepicker keep the date in the same format, and parse the date string correctly.

Please let me know your thoughts on this solution.
stevegibbings replied on at Permalink Reply
80%? Ah sarcasm. How utterly pointless and unnecessary.
andrew replied on at Permalink Reply
:( It actually wasn't sarcasm. I just found myself looking through the code certain that there must be a programmatic way through the date form helper to set the dateFormat and was mystified that we had never actually exposed a way to do that.
JedMeister replied on at Permalink Reply
So in short is there a way to fix this in the current stable version (5.4.2 - as downloaded from SF)?
I think I'm missing something. I'm a bit of a newb but fairly tech savy - in as much as I can follow basic instructions! :)

I've tried what's mentioned here (ie added the 3+1 lines to config/site.php) and it doesn't change the format in the dashboard. Or are the first 3 lines meant to go somewhere else?

I also had a look at and checked concrete/models/attribute/types/date_time/controller.php and it has the required line: $value = date('Y-m-d H:i:s', strtotime($value));

There is some more info here: but I can't make sense of what needs doing.

Help on how to set non-US default date (ie dd/mm/yy) would be muchly appreciated
andrew replied on at Permalink Reply
We should be releasing a point release next week that will have this in it.
JedMeister replied on at Permalink Reply
Thanks heaps Andrew.

Is there a thread/blog/RSS or something I can subscribe to so I know when it's released?

Also you may be interested to know what I'm up to. I've created a(n unofficial) Turnkey Linux (TKL) Concrete5 appliance which will lower the bar for end users that wish to install Concrete5 to their own hardware (or VM etc). I'm fairly confident that the core devs will release an official version sometime soonish. I know from reading your license that this is ok. But it'd be even better to have your blessing. :)
Have a look at Turnkey Linux here:
My TKLPatch is here:

PS Sorry to hijack your thread Steve.
olsgreen replied on at Permalink Reply
Should do the trick. Follow Andrews guide above, then:

Edit the line (141) in /concrete/helpers/form/date_time.php from:

$html .= '<script type="text/javascript">$(function() { $("#' . $id . '_dt").datepicker({ changeYear: true, showAnim: \'fadeIn\' }); });</script>';


$html .= '<script type="text/javascript">$(function() { $("#' . $id . '_dt").datepicker({ changeYear: true, showAnim: \'fadeIn\', dateFormat:\''.DATE_APP_DATE_PICKER.'\' }); });</script>';

Fixes the issue for me. (Must say, I haven't been through the code to see if there are any non-autostart implementations of this function in standard c5)
Hypocrite replied on at Permalink Reply
I am still running 5.4.2 because is not yet available through Dashboard.

But thought I still share this.

I have configured the date options for a Finnish date format in site.php like this:
define('DATE_APP_GENERIC_MDY', 'd.m.Y');
define('DATE_APP_GENERIC_MDYT_FULL', 'd.m.Y H:i:s');
define('DATE_APP_GENERIC_MDYT', 'd.m.Y H:i:s');
define('DATE_APP_DATE_PICKER', '');

But now if I go to the following pages and see the results:
You logged in on 09/05/11 at 7:01 PM.

15.02.2011 at 1:08:14 PM

The "at" word is always visible and so is the AM/PM ending. They must be hardcoded somewhere.
thuic replied on at Permalink Reply
'AM/PM': You forgot to put in config.php

'at': add translation files in languages folder.

But after all, in Dasboard (main page) you will see dates in xx/xx/xx format (like 31/01/2011).

I overcome this problem on my bilingual site (with new Internationalization addon active), with ‘old’ language switch code in config.php (see old posts on C5 forum):
// Including the DIR_REL and the Domain, the two language character en, hr.
$length_rel = strlen(DIR_REL);
$sitelang = substr($_SERVER['REQUEST_URI'],$length_rel+1, 2);
define('LANG', $sitelang);
switch($sitelang) {
   case 'en': {
      define('LOCALE', 'en_US');
   default: {
      define('LOCALE', 'hr_HR');

(Change ‘hr_HR’ to your locale)
Hypocrite replied on at Permalink Reply

I actually had the 24 settings in my site.php but adding the LC_ALL settings also seemed to make a difference in some pages.

I still have this 20.9.2011 at 10:59:55 PM in Jobs page though, so the settings does not affect every page.

But again a bit more forward. :)

I think these date and time settings should be added for example to the Multilingual page where the settings could be made centralized and you wouldn't have to seek out settings.
thuic replied on at Permalink Reply 1 Attachment
You are right.
Look what I am reading (attach.) - I did not notice that before.
I do not have AM/PM notification any more, but time is shoving 1:36 instead 13:36!
Hypocrite replied on at Permalink Reply
Yes, that's exactly what I am seeing in some places.

The settings are available in the site.php and some pages use them correctly. But then there are individual pages where some date or time format is not correct.
thuic replied on at Permalink Reply
Yes, may biggest problem was with date_nav block translation (especially when this block is called programmatically from scrapbook). If you need template, let me know.
JohntheFish replied on at Permalink Reply
I have been going round in circles on trying to get a date-time attribute to consistently work with European format date of either dd-mm-yy or dd/mm/yy, using the settings noted in this thread and variations of them. But I can't get it to work consistently without corrupting at some stage. So maybe the issue has been solved for forms, but not for the date-time attribute.

I have decribed in more detail and posted a bug report
JohntheFish replied on at Permalink Reply
I have just posted a 'tentative' correction for this on the above referenced bug report.
TheRealSean replied on at Permalink Reply
What is the situation on the European date format, now am I able to use


Previous attempts have always caused the date to reset, to 1970 which I am assuming is due to the parsing issue Andrew mentioned earlier, I am able to get dd-mm-yy to work but would prefer to be able to use "/" instead.

Is it safe to try using the "/" again?

This could do with being added to the developers guide.

simoneast replied on at Permalink Reply
As of concrete the datepicker() format used in custom forms appears to (sadly) be hard-coded in `/concrete/src/Form/Service/Widget/DateTime.php`.

The only way I found to change it was to inject the following Javascript in my page

$('.ccm-input-date.hasDatepicker').datepicker('option', 'dateFormat' ,'d M yy');
madesimplemedia replied on at Permalink Reply
Thank you, very useful to know :)