Date format wrong - MM/dd/yyy when it should be dd/MM/yyyy


Since when I installed version 7 I had this problem, the date format is wrong.

My locale is brazilian portuguese, but still , date format is wrong.


How to fix that?


This is the most critical problem for me, I'd be really  greateful if someone could help me with this...


Really don't want to push, but I'd really appreciate if someone could give an idea of how to fix to show the right format both for input and output of dates;



Hey , are you referring to Ushahidi v2.7.2? If this is a bug, would be great to have this over on




I checked my configuration, and in the combo which is selected Portugues (BR) the value is:
Português (BR)

Although when I looked at the incident table the field locale of every line has "en_US" as value.


Looking at the reports controller, I could find the following:

from line 284
// Initialize Default Values
$form['incident_date'] = date("m/d/Y",time());
$form['incident_hour'] = date('h');
$form['incident_minute'] = date('i');
$form['incident_ampm'] = date('a');
$form['country_id'] = Kohana::config('settings.default_country');

from line 618

$this->template->content->incident_date = date('M j Y', strtotime($incident->incident_date));
$this->template->content->incident_time = date('H:i', strtotime($incident->incident_date));

Seems like this is the default format is the month/day/year

As the database incident_date field seems corretct, I guess I could change the format on those two places to get the d/m/Y format, correct?

I believe the best solution would be to make the date format follow the locale.

What should I do with the locale on the report, is there anywhere that uses that value?



Actually there are more places where the date format is set this way:

\backups\files\ushahidi\application\controllers\admin\reports.php (4 hits)
Line 369: $form['incident_date'] = date("m/d/Y",time());
Line 466: $form['incident_date'] = date('m/d/Y', strtotime($message->message_date));
Line 534: $form['incident_date'] = date('m/d/Y', strtotime($feed_item->item_date));
Line 747: 'incident_date' => date('m/d/Y', strtotime($incident->incident_date)),

application\controllers\members\reports.php (3 hits)
Line 255: $form['incident_date'] = date("m/d/Y",time());
Line 324: $form['incident_date'] = date('m/d/Y', strtotime($checkin->checkin_date));
Line 480: 'incident_date' => date('m/d/Y', strtotime($incident->incident_date)),

application\controllers\reports.php (1 hit)
Line 284: $form['incident_date'] = date("m/d/Y",time());

application\views\admin\manage\actions\main.php (1 hit)
Line 415: <?php echo Kohana::lang('ui_admin.server_time').' '.date("m/d/Y H:i:s",time()).' ('.$site_timezone.')'; ?>

application\views\admin\settings\site.php (1 hit)
Line 107: <?php echo Kohana::lang('ui_admin.server_time').' '.date("m/d/Y H:i:s",time()).' ('.$form['site_timezone'].')'; ?>

tests\phpunit\classes\helpers\Reports_Test.php (1 hit)
Line 11: 'incident_date' => date("m/d/Y",time()),

As my main problem is submiting and view the report I just changed the application\controllers\reports.php on the lines:


$form['incident_date'] = date("d/m/Y",time());


$this->template->content->incident_date = date('j M Y', strtotime($incident->incident_date));

That seems to work, although the month is still shown in english "Aug" instead of portuguese "Aug", Is there a way to fix this? Or do I have to only use d/m/Y to avoid this?

Looking forward, it would be nice to have all date formatting in one single place and to have a dynamic way to configure date formatting using locale.


I also had to change the themes/default/views/reports/submit.php to:

$().ready(function() {
       showOn: "both",
       buttonImage: "<?php echo url::file_loc('img'); ?>media/img/icon-calendar.gif",
       buttonImageOnly: true,
       dateFormat: 'dd/mm/yy'


and also the detail.php on the same folder changed the format:


<?php echo date('H:i d/m/Y', strtotime($neighbor->incident_date)); ?>




Seems that the submit.php wasn't enough  when I try to submit a report I get:


  • O campo data parece não conter uma data válida.

That translates to "the field date doesn't seem to have a valid date"

I found here the following strings:

'incident_date' => array(
'date_ddmmyyyy' => 'O campo data parece não conter uma data válida.',
'date_mmddyyyy' => 'O campo data parece não conter uma data válida.',
'required' => 'É necessário preencher o campo data.',
Then searching through ushahidi I found:

Line 268: if ( ! valid::date_mmddyyyy($field_response))

Line 362: public static function date_mmddyyyy($str)
Line 384: public static function date_ddmmyyyy($str) 

Line 359: public static function date_mmddyyyy($str)

Line 371: public static function date_ddmmyyyy($str)

I presume that it is calling the mmddyyyy version of some of this functions. Is it on the customforms.php? Well, it looks like it doesn't, as I changed in there and I still get the validation error.
I then changed the /application/i18n/pt_BR/report.php to show which format it was the error and got (mmddyyyy), so it seems it is one of those function it is using. Which one is used? system\helpers\valid.php or application\helpers\valid.php, and why they have two different implementation for the same thing?

Ended up finding where to change /application/helpers/reports.php
Line  50 ->add_rules('incident_date','required','date_ddmmyyyy')

And a few files changed and many hours later, I got the dd/mm/yyyy format working, but I have to say that it was pretty difficul. Is my deployment the only one to have the requirement to use a different format?

I have noticed that the hour time is quite hard-coded as well, so I will leave it for now as am/pm instead of the 24hs used in Brazil, but it would help a lot if this was automatic.

Please let me know if I'm doing something really stupid and it was supposed to work either way.

Anyway, thanks a lot for delevoping such incredible too, hope that this can help other people like me.



Seems i got a side-effect after my changes. The start date is at 1969. 

I thought that the changes Ive made wouldn't affect anything else as the date itself were stored as date type in DB.

Any idea what can be?


I just tested and it seems that my change on the date broke something badly, I just added a report, but afterwards it can't be found.

That on top that when I try to edit on the admin page it fails as it tries to validate using the american format. :/ I suppose it's because I haven't change all of the pages


Just checked the database and it seems the incidents are being registered with wrong dates:
That means the changes I've done weren't enough.
Now I don't know if I just revert the changes or I try to fix it in other places. Any help would be really helpful.


I ended up reverting the changes, don't want to risk breaking the site again :/

But it would be really nice if we could have ushahidi dealing with date formats in a more transparent way



Hey ,

I started having a look, and this is a fairly major issue. As you pointed out, hardcoded references to the date format are all over the place, and we'll need to make sure this works for all localizations.

I suggest you open a ticket at mentioning all the instances you're having trouble with (double points if you have screenshots).


Pinging  here as it would be good to make sure this is treated properly on V3. 


I looked at this a long while back in 2.x .. its pretty much unfixable in 2.x without sweeping the entire codebase for date functions. Everything is hard coded

Its definitely something I've considered in V3. We've already limited dates to 2-3 formats and we'll probably swap in a decent Date localization+formatting library once we get further along.


Thanks for replying. A shame that I'll have to wait for V3 to have nice formatted dates.


It would be nice though if one would tell me where I should change to get it working with ddmmyyy, because the changes Ive done above weren't enoug...


You'll basically need to search the entire codebase for any PHP calls to the date() function. You'll also need to find any date handling in JS.. those are less clear however.


That's what I did above, but it seems something was missing