International Date Formats

That sounds strange, and I can't reproduce it.
Where exactly in the admin are you seeing this?

After some thought, it sounds to me like you didn't change the settings in includes/languages/<your language>.php.

First, copy that file to includes/languages/<your template>/<your language>.php, then open that file and make sure you have the correct date formats set up in the beginning of that file, example:

@setlocale(LC_TIME, 'no_NO');
define('DATE_FORMAT_SHORT', '%d/%m-%Y'); // this is used for strftime()
define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
define('DATE_FORMAT', 'd/m-Y'); // this is used for date()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

You'd also want to change the example date format further down that file, for instance:

// text for date of birth example
define('DOB_FORMAT_STRING', 'ddmmyyyy');

If that's not it, perhaps you should try to redo the instructions?

Added: after some more thought, I'm not really sure that's the problem anyway, but please try what I suggested.

If the above settings are correct and the problem still persists, try to:

replace this part :

**

@setlocale(LC_TIME, 'no_NO');

**

to :

@setlocale (LC_TIME, 'no_NO.ISO8859-1');

Then, replace this line :

**

define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()

**

for :

define('DATE_FORMAT_LONG', '%A %e %B %Y'); // this is used for strtime()

;)

Nop, still same problem. In the admin section when i'm looking under the Customers personal information, the Date of Birth says 2037.09.27 when i, in the form were you apply for an account, added 1963.09.27. Isn't it something in a admin file that should be changed? I don't know, your'e the experts.

Is there someway to make this just a text field, with no validation? I need to have this fixed.

Could you please see what it looks like in the database?

Go to the 'customers' table, and lookup the field 'customers_dob'.

Could you please post one of those entries?

It should look like this: "1963-09-24 00:00:00"

If it does, then my function has done what it's supposed to do, and the error must have something to do with perhaps any admin modules you've added? (just making a wild guess)

If it looks like "2037-09-24 00:00:00", then I'm a bit short on ideas, because I really can't understand why my function would do that. I'll have to investigate it further, but please post an entry from your DB first, so I'll have a clue of what's wrong.

And one more thing, did you try to redo all the steps from the beginning?

Yes, in the database it says 1963.09.27 00:00:00 and yes, i redid it again.

From the modifications I sent you, you'd 'also' need to apply this on your admin/includes/languages/<your_language>/<your_language>.php file.

This should resolve the issue. Sorry for the misinformation.

Keep this thread updated. ;)

Tell me this: When i enter 1963-09-27 it shows 2037-09-27 but if i enter 1973-09-27 it shows it right same with 1980 iex. It looks like from 1970 and up it works, from 1969 and down, not?!
What's that folks? :blink:

By the way, i canged it in the admin section as well.

To me it sounds like server issues, maybe the php version you're running.

Although I'm no expert on that area myself, maybe someone else would be able to help you if you posted some server info.

Go to 'admin->tools->server info' and post the first few lines of that page. (Server OS, PHP version, database, http server).

Also, have you installed any extra admin modules (contributions)?
In that case, which ones?

Server Host: ()
Database Host: localhost (127.0.0.1)
Server OS:  	
Database: MySQL 4.0.24_Debian-2-log
Server Date: 2005-04-05 16:08:58
Database Date: 2005-04-05 16:08:58

Server Up Time:
PHP Version: 4.3.11 (Zend: 1.3.0)
HTTP Server: Apache

No extra modules installed.

I made all the changes suggested and now when I enter a new customer I get the following .

Warning: Cannot modify header information - headers already sent by (output started at /home/penturne/public_html/catalog/includes/languages/english.php:662) in /home/penturne/public_html/catalog/includes/functions/functions_general.php on line 52

What extra information do I need to post to get some help. When it comes to code I am so far below novice it is not funny. :blink:

Thanks in advance

**

Warning: Cannot modify header information - headers already sent by (output started at /home/penturne/public_html/catalog/includes/languages/english.php:662) in /home/penturne/public_html/catalog/includes/functions/functions_general.php on line 52

**

Make sure not to leave any white space on these statements. This should clear out these errors. ;)

**Make sure not to leave any white space on these statements. This should clear out these errors. **

Excellent thanks heaps fixed it up nicely :D

Wondering if anyone can offer advice here:

Trying to get this going on a clean installation under ZenCart 1.2.5d (with patch 6), the zen_date_raw function works fine and converts anything to dd/mm/YYYY as expected (using custom/english.php with the system locale set to en_AU

However, the advanced_search code doesn't seem to work at all. I've edited the stock files (it seems you can't use custom/ files for functions/) but unless the date is DD/MM/YYYY, it pops up an error dialog that says:

*Invalid From Date
*Invalid To Date

Regardless of the date entered?!?

Thanks in advance,

Paul

Well it's been a while since I've looked at these functions, but when I look at it now I'm a little puzzled myself.. I know that it used to work on my old setup, but when I try it from the start now, I see that there's some javascript kicking in, complaining about non-valid date formats. Maybe there was something I forgot I had done when posting this earlier.

What you need to do, is either remove the javascript check, or make up a new javascript date validator function or tweak the old one somewhat. Guess which one is easier.

I'm not a big fan of javascript, so my best bet is that I removed the javascript code, as it's totally unnecessary, and IMO just cluttering up the code.

Sure, it can save you the time it takes to reload the page, but it also adds to the size of the page. IMO it's rarely worth it.

Here's how to remove the javascript that validates the form before submitting:

Edit includes/templates/<your template>/templates/tpl_advanced_search_default.php:
Replace line 23:

<?php echo zen_draw_form('advanced_search', zen_href_link(FILENAME_ADVANCED_SEARCH_RESULT, '', 'NONSSL', false), 'get', 'onsubmit="return check_form(this);"') . zen_hide_session_id(); ?>

with the following

<?php echo zen_draw_form('advanced_search', zen_href_link(FILENAME_ADVANCED_SEARCH_RESULT, '', 'NONSSL', false), 'get') . zen_hide_session_id(); ?>

That's basically it, but you can also remove the now unused javascript code for that page, from includes/modules/pages/advanced_search/jscript_main.php:

function check_form() {
 var error_message = "<?php echo JS_ERROR; ?>";
 var error_found = false;
 var error_field;
 var keyword = document.advanced_search.keyword.value;
 var dfrom = document.advanced_search.dfrom.value;
 var dto = document.advanced_search.dto.value;
 var pfrom = document.advanced_search.pfrom.value;
 var pto = document.advanced_search.pto.value;
 var pfrom_float;
 var pto_float;

 if ( ((keyword == '') || (keyword.length < 1)) && ((dfrom == '') || (dfrom == '<?php echo DOB_FORMAT_STRING; ?>') || (dfrom.length < 1)) && ((dto == '') || (dto == '<?php echo DOB_FORMAT_STRING; ?>') || (dto.length < 1)) && ((pfrom == '') || (pfrom.length < 1)) && ((pto == '') || (pto.length < 1)) ) {
  error_message = error_message + "* <?php echo ERROR_AT_LEAST_ONE_INPUT; ?>\n";
  error_field = document.advanced_search.keyword;
  error_found = true;
 }

 if ((dfrom.length > 0) && (dfrom != '<?php echo DOB_FORMAT_STRING; ?>')) {
  if (!IsValidDate(dfrom, '<?php echo DOB_FORMAT_STRING; ?>')) {
   error_message = error_message + "* <?php echo ERROR_INVALID_FROM_DATE; ?>\n";
   error_field = document.advanced_search.dfrom;
   error_found = true;
  }
 }

 if ((dto.length > 0) && (dto != '<?php echo DOB_FORMAT_STRING; ?>')) {
  if (!IsValidDate(dto, '<?php echo DOB_FORMAT_STRING; ?>')) {
   error_message = error_message + "* <?php echo ERROR_INVALID_TO_DATE; ?>\n";
   error_field = document.advanced_search.dto;
   error_found = true;
  }
 }

 if ((dfrom.length > 0) && (dfrom != '<?php echo DOB_FORMAT_STRING; ?>') && (IsValidDate(dfrom, '<?php echo DOB_FORMAT_STRING; ?>')) && (dto.length > 0) && (dto != '<?php echo DOB_FORMAT_STRING; ?>') && (IsValidDate(dto, '<?php echo DOB_FORMAT_STRING; ?>'))) {
  if (!CheckDateRange(document.advanced_search.dfrom, document.advanced_search.dto)) {
   error_message = error_message + "* <?php echo ERROR_TO_DATE_LESS_THAN_FROM_DATE; ?>\n";
   error_field = document.advanced_search.dto;
   error_found = true;
  }
 }

 if (pfrom.length > 0) {
  pfrom_float = parseFloat(pfrom);
  if (isNaN(pfrom_float)) {
   error_message = error_message + "* <?php echo ERROR_PRICE_FROM_MUST_BE_NUM; ?>\n";
   error_field = document.advanced_search.pfrom;
   error_found = true;
  }
 } else {
  pfrom_float = 0;
 }

 if (pto.length > 0) {
  pto_float = parseFloat(pto);
  if (isNaN(pto_float)) {
   error_message = error_message + "* <?php echo ERROR_PRICE_TO_MUST_BE_NUM; ?>\n";
   error_field = document.advanced_search.pto;
   error_found = true;
  }
 } else {
  pto_float = 0;
 }

 if ( (pfrom.length > 0) && (pto.length > 0) ) {
  if ( (!isNaN(pfrom_float)) && (!isNaN(pto_float)) && (pto_float < pfrom_float) ) {
   error_message = error_message + "* <?php echo ERROR_PRICE_TO_LESS_THAN_PRICE_FROM; ?>\n";
   error_field = document.advanced_search.pto;
   error_found = true;
  }
 }

 if (error_found == true) {
  alert(error_message);
  error_field.focus();
  return false;
 } else {
  RemoveFormatString(document.advanced_search.dfrom, "<?php echo DOB_FORMAT_STRING; ?>");
  RemoveFormatString(document.advanced_search.dto, "<?php echo DOB_FORMAT_STRING; ?>");
  return true;
 }
}

The entire above function can be removed.

This will remove the client-side date validation. Keep in mind that the validation is still done server-side, with php.

^ I was having the same problem, and I made those code changes. Now the java pop-up doesn't appear, but two bright red boxes with exactly the same "invalid from date" & "invalid to date" appear on the page on the refresh after click the search button ::frust

-Luke

Thanks, that works 'more' than it did -- entering dates such as:

DD/MM/YY
DD/MM/YYYY
DDMMYY
DMYY

work.

however, entering a date like:

5 June 05

doesn't. (printing the same red-boxed PHP warning that EseentialParadox has)

still, it looks a whole lot more professional than it did ::tup

Paul

EssentialParadox:

^ I was having the same problem, and I made those code changes. Now the java pop-up doesn't appear, but two bright red boxes with exactly the same "invalid from date" & "invalid to date" appear on the page on the refresh after click the search button ::frust

-Luke
Did you set the constant DATE_FORMAT correctly?

If you're not sure, open includes/languages/<your language>.php or the proper over-ride file if you have one, and check that the date format you want is set correctly.

For example, I have this:

define('DATE_FORMAT', 'd/m-Y');

But if this is happening no matter what date you insert, you should probably start over and make sure you get everything right.

dwno:

EssentialParadox:

^ I was having the same problem, and I made those code changes. Now the java pop-up doesn't appear, but two bright red boxes with exactly the same "invalid from date" & "invalid to date" appear on the page on the refresh after click the search button ::frust

-Luke
Did you set the constant DATE_FORMAT correctly?

If you're not sure, open includes/languages/<your language>.php or the proper over-ride file if you have one, and check that the date format you want is set correctly.

For example, I have this:

define('DATE_FORMAT', 'd/m-Y');

> 
> But if this is happening no matter what date you insert, you should probably start over and make sure you get everything right.
 So I should have what you have? Or do I have a choice of other things I should put?

funkey:

Thanks, that works 'more' than it did -- entering dates such as:

DD/MM/YY
DD/MM/YYYY
DDMMYY
DMYY

work.

however, entering a date like:

5 June 05

doesn't. (printing the same red-boxed PHP warning that EseentialParadox has)

still, it looks a whole lot more professional than it did ::tup

Paul
This should also work, so I think you just forgot one small step.

Make sure you have defined the constant MONTH_ABBR, which is only used by my functions.

A sensible place to define it is in includes/languages/<your language>.php or if you're over-riding it, includes/languages/<your template>/<your language>.php

If you followed the instructions carefully you should have done this already.

The line should look somewhat like this (note that these abbreviations are in norwegian);

define('MONTH_ABBR', 'jan feb mar apr mai jun jul aug sep okt nov des');

Note that the abbreviations are separated only by a space.