Struggling with non US date format (all my hair has gone!)
Permalink 1 user found helpful
Please help I pulled out all my hair over this!
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 Concrete5.6.2.1. 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.
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 Concrete5.6.2.1. 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.
Thanks JTF, I installed your constants add-on and is indeed helpful.
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.
So frustrating!
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.
So frustrating!
Maybe this pull (in 5.6.3)
https://github.com/concrete5/concrete5/pull/1604...
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).
EDIT
See
https://www.concrete5.org/documentation/background/version_history/5...
2/3 down Miscellaneous Improvements
You can see back through the bug reports
https://www.google.co.uk/search?q=site%3A+concrete5.org%2Fdevelopers...
https://github.com/concrete5/concrete5/pull/1604...
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).
EDIT
See
https://www.concrete5.org/documentation/background/version_history/5...
2/3 down Miscellaneous Improvements
You can see back through the bug reports
https://www.google.co.uk/search?q=site%3A+concrete5.org%2Fdevelopers...
Okay thanks, great info, I'll try testing 5.6.3RC2.
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.
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.
Tested 5.6.3RC2, although I had to do a fresh install as upgrade failed, unsure why.
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.
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.
5.6.3 RC didn't include an updater. Updaters are only added to official releases.
The really good news is that 5.6.3 is now officially released, so includes the updater.
The really good news is that 5.6.3 is now officially released, so includes the updater.
Ah, that explains it. Thank you.
Although version 5.6.3RC2 fixed the date format issue, it seems that production release 5.6.3.1 no longer contains the fixes. Doh!
As mentioned here:http://www.concrete5.org/developers/bugs/5-6-3-1/ddmmyyyy-date-form...
There was a fix but unfortunately, I'd contained another problem which caused more problems. That's why it was reverted..
There was a fix but unfortunately, I'd contained another problem which caused more problems. That's why it was reverted..
Thanks Remo, now I understand the issues. I hope it can be fixed for the next version.
As far as I know, these changes work:https://github.com/concrete5/concrete5/pull/1670/files...
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.
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.
Okay, thanks again. I'll have a look. Although a little reluctant to use code outside the main release on a production website.
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.
Jon.
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.
Jon.
Zend_Date won't help here, it's a client side issue.
Problem is that the date picker has to display the date in a user specific format on the client, but send it to PHP in a machine readable form. It's all JavaScript at this point..
Problem is that the date picker has to display the date in a user specific format on the client, but send it to PHP in a machine readable form. It's all JavaScript at this point..
What is the latest news on this issue please?
I am using 5.6.3.2a1 and my config file contains the following:
define('DATE_APP_GENERIC_MDY','j/n/Y');
define('DATE_APP_GENERIC_MDY_FULL','d F Y');
define('DATE_APP_GENERIC_T','g:ia');
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');
define('DATE_APP_DATE_PICKER', 'dd-mm-yy');
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.
I am using 5.6.3.2a1 and my config file contains the following:
define('DATE_APP_GENERIC_MDY','j/n/Y');
define('DATE_APP_GENERIC_MDY_FULL','d F Y');
define('DATE_APP_GENERIC_T','g:ia');
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');
define('DATE_APP_DATE_PICKER', 'dd-mm-yy');
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.
can you please check if those changes work for you?https://github.com/concrete5/concrete5/pull/1782...
OK, excuse my naivety with GitHub but do I need to make 140 additions and 64 deletions, or can I simply download copies of the changed files?
Well, git provides a number of great tools to merge such changes but it has a certain learning curve. Takes a while to get used to.
Github offers a direct download link, never used it, but it should work as wellhttps://github.com/mlocati/concrete5/archive/fix-jqueryuidatepicker....
Github offers a direct download link, never used it, but it should work as wellhttps://github.com/mlocati/concrete5/archive/fix-jqueryuidatepicker....
I have replaced the following files with the ones in mlocati's fix package, on my dev core:
concrete/config/localization.php
concrete/core/helpers/date.php
concrete/core/helpers/form/date_time.php
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.
concrete/config/localization.php
concrete/core/helpers/date.php
concrete/core/helpers/form/date_time.php
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.
thanks for the feedback, appreciate it!
hey there,
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?
Cheers!!
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?
Cheers!!
that's because I've merged that branch, you can download the master branch now
https://github.com/concrete5/concrete5/archive/master.zip...
https://github.com/concrete5/concrete5/archive/master.zip...
Hi
This sounds like it would resolve my problem (in UK running 5.6.3.1). 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!
This sounds like it would resolve my problem (in UK running 5.6.3.1). 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!
Best to upgrade the whole instance.
http://www.concrete5.org/documentation/how-tos/developers/manually-...
http://www.concrete5.org/documentation/how-tos/developers/manually-...
be careful with this, the github version contains PHP short tags and other things. I strongly recommend that you run the build scripts first! Requires a few things to get it working though, check these instructions
https://github.com/concrete5/concrete5/tree/master/build...
https://github.com/concrete5/concrete5/tree/master/build...
Bingo, all working. Thanks so much.
Help please! I don't know whether people will spot this resurrected thread and give me a hand, or whether I ought to start a new thread.
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 5.6.3.3 atm
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 5.6.3.3 atm
Hi,
Version 5.6.3.3 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.
Version 5.6.3.3 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.
Thanks adaptive, I appreciate you getting back to me.
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)
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)
I'm glad you were able to fix your problem.
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.
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.
> I'm glad you were able to fix your problem.
Me too!
>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.
Me too!
>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'm glad I could help.
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.
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.
As I mentioned in http://www.concrete5.org/index.php?cID=113666...
In concrete 5.7.5.2 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
In concrete 5.7.5.2 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');
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.