I have this problem also. I have the date set to show as Septiembre 22, 2006 (Spanish) and have the same problem when trying to edit a post. The error is "Please enter a valid issue date."

Using English UK (using a long date) causes the same issue. A workaround is setting your user profile to English US, and using the US formatted date instead.

It's tied to the date format, not the locale itself.

I have also noticed that the date format is not very friendly to foreign (as far as English is concerned) languages. For instance, in Spanish a common long date format is "24 de septiembre, 2006" but I cannot specify this format because the word "de" is translated to some date fields. I wanted to try entering it like this: "j \d\e F, Y" but there is not enough space in the form field to enter that. Due to this I have to use (also common but not the preferred one in Spanish) "Septiembre 24, 2006" format. The blogs will be in Spanish in an all-Spanish web site, so switching to a locale in English is not an option.

And to comment on Paul's suggestion, yes using a locale with short date is a workaround. I set the admin user to a locale different from the default blog locale and I can change timestamp on posts.

But this is still a bug.

Just for info: I've bumped the size of the input field (for time and date) to 20, instead of 10.

I've also found the root of the problem you're describing: only "d", "m", "y" and "Y" get considered in the conversation routines.

I'll probably finish this tomorrow and it will be in 1.9 and perhaps in 1.8.3 - until then, you can only use the above letters.

btw: also escaping the letters, like "d" in "\d\e" in your example currently does not work, but will in the fixed version.

This should work now with 1.9-beta - not yet released, but available at the demo site:
http://demo.b2evolution.net/?revision=beta

Please test it there and report back.

Is this something that can be hacked into 1.8.2 in the mean time? I find this bug and limitation in field size annoying.

Yes, sure. But taking together the snippets would me cost too much time, sorry. I've spent most of the last two b2evo-hacking-times on this issue.

I consider it also as a fix, but because it requires adjusting the DB table layout (loc_datefmt in evo_locales), it's a no-no for 1.8.3.

If we were using CVS instead of SVN, I could provide you a diff/patch easily, but we're still on CVS.

Apart from that: does it work on the demo for you?

Just did some testing in the demo.

I tried to put a long format date to a locale in the regional settings page of the back office and that form won't allow me to enter the long format such as the example I gave previously like this: j \d\e F, Y.

I still see the problem with the date on edit. If the locale has a long format (actually I think the problem is with the textual month) I will still get the invalid date on save because the full translated date appears in the time stamp field. Previous problem showed the untranslated date format code.

Don't know if the demo blog settings revert to their original values after some time but at the time I am writing this the default locale for the demo blog has the date set as j F, Y which causes the problem when saving an edited post. Try it or just put back that format in the default locale and try to edit a post.

Has probably just been reset (it's always at about quarter past).

So, it sounds like you've not used 1.9-dev (through the link provided above or from the dropdown in the "demo variants" menu), because it (seems) to work alright for me.

Oh no... I used the running demo which says 1.8.3. My blog is almost ready to go live and don't want to mess with it anymore with a non-production version.

Thanx for the answer.

Anyway, i think i can wait for the release of the 1.9 as the date display is for me purely cosmetic.

Gonna try tonight at home on the demo server and give some feedback :)

I also have this bug. I have 1.8.2 installed with only us-en locale and I only use the little popup calendar, and it still doesn't work. Well not being able to updated any posts was unacceptable to me , so I was able to work around this nasty bug by simply commenting out the part of the "edit" code that saves the date info. The negative side effect is that you can't update post dates, but on the other hand it doesn't work anyway so no big loss.

To be able to edit posts (except for the post date and time), do this. Open the file ./blogs/inc/MODEL/items/_item.class.php for editing. Inside this file, find the function called load_from_Request. Inside this function, look for this code:

if( ( $force_edit_date || $Request->param( 'edit_date', 'integer', 0 ) )
		&& $current_User->check_perm( 'edit_timestamp' ) )
{ // We can use user date:
	$Request->param_date( 'item_issue_date', T_('Please enter a valid issue date.'), true );
	$Request->param_time( 'item_issue_time' );
	$this->set( 'issue_date', form_date( $Request->get( 'item_issue_date' ), $Request->get( 'item_issue_time' ) ) ); // TODO: cleanup...
}

Now, comment out the three lines inside the brackets. This will basically skip this date checking function. Note that this will not cause DB problems because you aren't putting bad or malformed data into the DB, you're just not saving the date/time fields at all.

Now you can edit posts without having the date/time string goof it up. I didn't have time to hack the inside of the param_date function, but I may do that later this weekend.

I finished a hack to fix this issue. This fix uses the php function strtotime(), which assumes that you are using English language dates. I am not familiar with other locales so I couldn't do any testing. Sorry I couldn't get it any better, but hey it isn't my bug anyway. ;) Maybe someone else could expand it.

If you followed my above post as a temporary fix, uncomment those three lines and get back to normal. There are only two things to do for this fix.

First, open this file: ./blogs/inc/_misc/_form.class.php and find the member function date()

Look for this line in that function:
$field_params = array( 'date_format' => $date_format, 'type' => 'text' );

Change it to this line:
$field_params = array( 'date_format' => $date_format, 'type' => 'text', 'maxlength' => '' );

This will get rid of the maxlength variable in the HTML form which is silly and prevents you from typing in a date longer than ten characters. Now we can type in whatever we want. Don't worry, we'll still error check as much as we can.

Second, open this file: ./blogs/inc/_misc/_request.class.php and find the member function param_check_date()

Look for these lines at the very end of that function:
// Date did not pass all tests:
$this->param_error( $var, $err_msg );
return false;

Just before these lines, add this extra code:
$unix_timestamp = strtotime( $this->params[$var] );
if( checkdate( date("m",$unix_timestamp), date("d",$unix_timestamp), date("Y",$unix_timestamp) ) ) {
$iso_date = date( "Y-m-d", $unix_timestamp );
return $iso_date;
}

This will take whatever English string you type in to the date field and try to intelligently turn it into a unix timestamp. We check this stamp as a valid date (and return an error if not), then format it as b2e requires and go.

This fix requires no changes to the database or anything. It isn't very efficient since we are using the PHP date function four times, but it works correctly. I have tested it both with editing current posts and writing new ones, and so far have no errors.

The only issue is that you have to type in the date you want, the calendar plugin doesn't work properly if you use this fix. The plugin puts php date codes in the field (l, y, d, etc as discussed earlier in the thread), whereas this fix takes regular, normal input and creates a date out of it.

Hope this helps.

voltaic> Thanks man, I use English dates, it worked fo me though I added a comment

// date hack by voltaic for editing posts - 6-nov-2006

in case you find a permanent fix for it :-)