Struggling with non US date format (all my hair has gone!)1 user found helpful
All I want is for dates in forms and the datepicker to be in DD/MM/YYYY format and not in MM/DD/YYYY format.
I have config defines in site.php as follows:
For example, if I enter today's date 12/03/2014 in to a page's date property. It saves okay. If I re-edit the page properties I has changed to 03/12/2014. The date picker also interprets the date in the US format.
I'm using Concrete126.96.36.199. Can I use the 'localization' add-on to address this? I haven't tried, as I got the impression that was only for handling different languages which I don't want.
There are plenty of forum posts on this topic but majority are pre version 5.6.
Advice welcome, or at least send me a toupée.
Internationalisation of system dialogs was one of the main features of c5.6.3 (currently awaiting release), so if there is an issue with a date field not responding to the constants, it may well be covered by c5.6.3.
I changed my entries in site.php
The date picker format seem not to be the same as PHP date format. In order to get leading zeros I had to use 'dd' rather than 'd' etc.
So now the datepicker is respecting the value shown in date fields reading and writing. However, when saving a form e.g. page properties, the date must be saving incorrectly as upon re-examination of the page date the day and month have swapped. This results in 12/03/2014 read back as 03/12/2014 or 13/03/2014 read back as 01/01/1970 (probably because 03/13/2014 is invalid).
It is not obvious to me which other constants are used to parse the date when saving to the database.
There are some other pulls further back, so if you want to patch your own core you will need to bring in everything related. It may just be easier to use 5.6.3RC2, or to upgrade to it when it is released (allegedly soon).
2/3 down Miscellaneous Improvements
You can see back through the bug reports
Much of what I could make out from the changes seemed to relate to the date picker rather than the processing of submitted form data. Anyway, I'll install on my dev site and report back.
I can confirm that this version fixes the date save errors when using dd/mm/yyyy format dates as configured using defines in /config/site.php.
JTF - thank you for your help.
The really good news is that 5.6.3 is now officially released, so includes the updater.
There was a fix but unfortunately, I'd contained another problem which caused more problems. That's why it was reverted..
Only down-side, you won't be able to clear a date field once you've selected a date. That functionality isn't included in the jQuery UI datepicker and requires some code hacking.
I say, it would be great if Concrete harnessed Zend_Locale and Zend_Date but I understand the issues related to supporting legacy code and third party libraries.
Thanks for your continued help and feedback on this issue, much appreciated.
I am using 188.8.131.52a1 and my config file contains the following:
define('DATE_APP_GENERIC_MDY_FULL','d F Y');
define('DATE_APP_GENERIC_MDYT','j/n/Y \a\t g:ia');
define('DATE_APP_GENERIC_MDYT_FULL','dS F Y \a\t g:ia');
Whenever a Page Properties dialogue box is opened, concrete5 populates the page’s ‘Public Date/Time’ field in US format (m/d/y) such that when saved, the page’s creation date is often wrong when converted to UK format. This is a particular problem with blog posts and news articles. A workaround is to always re-select the date using the date-picker before making any updates to the Page Properties dialogue box, which will then insert the date in the correct UK format (dd-mm-yy), but the various users of our systems generally fail to remember to do this.
Github offers a direct download link, never used it, but it should work as wellhttps://github.com/mlocati/concrete5/archive/fix-jqueryuidatepicker....
The date being populated in the 'Public Date/Time' field of the Page Properties dialogue box is exactly the same (d/m/y) but now the page's timestamp is remaining as expected for the UK, so my initial findings are that this fix works (with no errors) :)
I have yet to do a more thorough test, or to roll out the fix to the production core.
can't seem to get the direct link to work - just get file not found error.
Anyone else get that? Or does anyone have the zip they could send to me?
This sounds like it would resolve my problem (in UK running 184.108.40.206). I've downloaded the new Master, but not sure what is the best thing to do. Do I replace my whole concrete folder with this new one, or just move key files? Any help appreciated. I'm a fast learner who wants to learn!
I've just spent an hour or so going through the forums, trying (and failing) to solve a problem I have with the date picker in a form not playing nicely with UK dates. I've found about 5 different posts (this is the most recent) and I swear they all have different answers. This one loses me towards the end as I'm not really a programmer and the intricacies of git etc. are beyond me
Could someone help me out with what is the best-practice currently available fix for site.php, and whether I need to change anything else as well? I would be extremely grateful. Thanks
Oh and I'm on 220.127.116.11 atm
Version 18.104.22.168 should be okay working with dd/mm/yyyy date formats as described in my original post above.
You need to ensure that your site.php file has the relevant entries in order that the Concrete5 defaults (US) are overridden.
I found the following entries worked for me:
However, it should be noted that these date definitions may not work with some add-ons because the add-on developer decided not to support other date formats. If this is the case then you should progress the issue with the add-on developer.
I figured out that my problem was probably because I had defined DATE_APP_DATE_PICKER, but I didn't have it matching DATE_APP_GENERIC_MDY
so I think what was happening was that the date field on my form auto-populated with today's date in DATE_APP_GENERIC_MDY format, whereas I then wanted to manipulate the date from the form which I had assumed would be returned in DATE_APP_DATE_PICKER format.
If someone didn't bother to choose a date and left it on today's date, the form wouldn't send me an email on submission and just gave a fatal error along the lines of 'date was a non-object'.
Does that make sense?
What I have now, which seems to be working, is the following:
define('DATE_APP_GENERIC_MDY','d M yy');
define('DATE_APP_DATE_PICKER', 'd M yy');
along with some other defines people suggested which I don't think are relevant to the form date.
I appreciate that d M yy is perhaps not very standard (it's just that site users wanted the M...) and so I'm hoping it won't break anything else? Is it likely to? This particular site is fortunately pretty small and only has one form, datepicker isn't used elsewhere.
Oh and actually even though I have set 'd M yy' I seem to be getting 'dd M yy' displayed - I would prefer d but am kind of past caring too much about that as long as it works!! Will it automatically turn d into dd so it can parse correctly? (or something... as I said I'm not good with php)
The non object error you were seeing is probably related to PHP being unable to convert the date string passed from the form in to a date object.
The other important factor to remember is that the date picker format is different. It is used by the jQuery datepicker widget (http://api.jqueryui.com/datepicker/#utility-formatDate) and the other formats are PHP date (http://php.net/manual/en/function.date.php).
Therefore, where you have defined 'd M yy' for both settings it may yield problems. For the datepicker 'd' = day with no leading zero, 'yy' = 4 digit year. For the generic formats 'd' = day WITH leading zero, 'yy' = 2 digit year followed by another 2 digit year. Short name month 'M' is the same for both.
In your case if you want no leading zero days and a four digit year your formats should be:
Hope that helps.
EDIT - I added the generic format for date and time, I recommend you have all three in your site.php.
>The non object error you were seeing is probably related to PHP being unable to convert > the date string passed from the form in to a date object.
yes I'm pretty sure that's exactly what it was
>The other important factor to remember is that the date picker format is different.
That was the bit I hadn't got my head round. I've just put your suggested settings in site.php and finally it appears to be working exactly as I want it... so you have been super helpful!
I still think we need better support for those of us in the UK or other non-US locations trying to deal with this kind of issue. In some cases correct date formatting can be vital but the documentation for changing it seems non-existent, so people are working on trial and (lots of) error.
I haven't had time or energy to look at 5.7 properly yet - would be interesting to know if it's any better.
I agree the docs for 5.6 are lacking in some areas, but remember Concrete5 is an open source project and the vast majority of what you are using is contributed by good people who freely give their time.
You should take a look at 5.7 the content editor user experience and workflow is different and better on the whole. However, there is no upgrade path from 5.6 to 5.7 as 5.7 has significant architectural differences.
Sadly, I've had to go back to Wordpress as their simply isn't the breadth of quality plug-ins that my clients require. Concrete5 still trumps Wordpress for intuitive content editing.
In concrete 22.214.171.124 the datepicker() format used in custom forms appears to (sadly) be hard-coded in /concrete/src/Form/Service/Widget/DateTime.php.
$('.ccm-input-date.hasDatepicker').datepicker('option', 'dateFormat' ,'d M yy');