Parsing english dates

[hessodreamy]

Is there a nice, flexible way of getting a timestamp for an english date ie dd/mm/YY
strtotime is a great function in that you don't need to know exactly what format the input is in. If only there were some way of doing the same for english format dates??

[php_daemon]

$str='12/11/2007';
 
$date=explode('/',$str);
 
echo date('Y m d',mktime(0,0,0,$date[1],$date[0],$date[2])); //2007 11 12

[hessodreamy]

yes but then you'd need to know how the date is delimited. And include extra options if you wanted to (optionally) include the time or day of week elements.
Basically, before I write some big pettern matching extravaganza, I was wondering if I'm missing something that's already been done?

[php_daemon]

Well, then perhaps something along the lines:

$str='12/11/2007';
 
$date=preg_split('#[-/. ]#',$str);
 
print_r($date);
 
echo date('Y m d',strtotime($date[1].'/'.$date[0].'/'.$date[2])); //2007 11 12

That is switching the month/day pair places.

[Cups]

Where is the english date coming from and exactly what do you want to do with it next?

[hessodreamy]

Most common case is that the date has come from user input, and I'll probably convert it into the correct format and maybe to put it into the database as datetime type.

[Jake Arkinstall]

User inputs can be a big problem - I think your best option is to provide drop-down boxes, or some other form of graphical format.

Maybe 2 textboxes, but the time format is specified by the label, e.g.:

Date (mm/dd/yy): [__]/[__]/[____]

[hessodreamy]

What I have is a nice little javascript date selector which allows the user to select a date and pops it in to the text box in the correct format.

But obviously you need to account for non-js users. Personally I like to keep the date input to 1 form element, and validate it.

I basically wondered if I was missing some super date-parsing function. I'll go work on some validation/flexible pattern matching, and post back.

[stereofrog]

preg_match_all('~\d+~', $str, $m);
$m = $m[0] + array_fill(0, 6, 0);
$time = mktime($m[3], $m[4], $m[5], $m[1], $m[0], $m[2]); 

This will parse "11/12/2007" and something like "11.12.7 2h 15min" as well.

[Cups]

>But obviously you need to account for non-js users. Personally I like to keep the date input to 1 form element, and validate it.

That's a mistake in my view. Users will inevitably get it wrong.

It depends how much effort you want to put into getting this right for the user.

A US citizen living in the UK will give you duff data, like 1/2/2008 which you will go ahead and parse as 1st Feb, when she means 2nd Jan.

Its a valid date.

As for your gui, a nice no-script option is simply to write 3 date boxes using range() with correctly marked labels. eg

echo '<noscript>';
echo '<select name='day' id='day'>';
$days = range( 1,31);

foreach( $days as $d){
echo '<option value='.$d.'>'.$d.'</option>';
}

echo '</select>';
// and so on for the month and year

echo '</noscript>' 

So what you are left with is a non-javascript user who enters a non-existent date ( like 31st of Feb ) so you run the result through the PHP function checkdate().

Incidentally you could run checkdate() over all incoming dates, even results from your JS enabled users, so you don't enter bad data in your dbase.

Why would you want to checkdate() dates from your JS calendar? Because users can change this data at will - something you would want to check for and snag before you go off doing anything else with the submitted data.

[spikeZ]

There are so few users who dont have javascript enabled in the real world that it's not a big worry really, yes offer an alternative but dont base everything on it.

The less chance the user has of incorrect input the better.
Give them the three dropdowns with really big labels and maybe visual hints like tootips.

[Cups]

Hi,

I tend to agree with Spike, though hessodreamy mentioned non-js - and I didn't spell it out implicitly, but you could use a range-type generator or just plain hard-coded html select boxes instead of JS.

(The clever thing with JS is that you are assured that the input boxes, when you select Feb for example will only create 28 (or 29) days)

But either way you still you need to check the date is a real one.

If date handling is new to you, then I'd say this method is a pretty simple way to go - sidestepping the onerous and sometimes bug-ridden task of exploding, rebuilding and verifying dates entered via freeform text boxes.

HTH

Paul

[hessodreamy]

I would tend to agree with you regarding the use of selects, for a public website. You can't trust the user to not be a thicko or, on the other hand, an american () and enter the date incorrectly. I like cups' dual method of using selects for those without js.

However what I'm working on right now is a back-office admin page so it means 1) I can rely a little more on the user 2) They're doing repetitive jobs so quick and easy is the way (ie not having a row of 3 selects).

But such usability talk is a bit off topic.

Regarding the parsing of dates. When I come down to it, all I'm doing is 2 things:
1. getting a datetime from the database and displaying it in some format
2. Getting some user-entered date and putting it in the database as a datetime

To this end I just came up with 2 pretty simple functions to do this:

function date_to_db($dateStr)
{
	//split it
	$ukDatePattern="/^([0-9]{1,2})[\/\.,\- ]([0-9]{1,2})[\/\.,\- ]([0-9]{2,4})( ([0-9]{1,2}) ?: ?([0-9]{1,2})( ?: ?([0-9]{1,2}))?)?$/";
	if(!preg_match_all($ukDatePattern, $dateStr, $matches)) return false;
	if(count($matches)<3) return false;
	$d=$matches[1][0];
	$m=$matches[2][0];
	$y=$matches[3][0];
	
	//check parts
	if(!checkdate($m,$d,$y)) return false;
	
	//stick it back together
	$dbDate=$y."-".$m."-".$d;
	
	//check for time elements
	if($matches[5][0]!="")
	{
		$dbDate.=" ".$matches[5][0];
		$dbDate.=":".$matches[6][0];
		if($matches[8][0]!="") 
		{
			$dbDate.=":".$matches[8][0];
		}
	}
	return $dbDate;
}
function date_from_db($dateStr,$format="d/m/Y")
{
	$stamp=strtotime($dateStr);
	if($stamp==-1) return false;
	return date($format,$stamp);
}

I was basically wanting to check I wasn't re-inventing the wheel. It's been a fun journey and we got there in the end. Cheers

[Cups]

>However what I'm working on right now is a back-office admin page so it means 1) I can rely a little more on the user

Nah, it means you can punish them!

>2) They're doing repetitive jobs so quick and easy is the way (ie not having a row of 3 selects).

Of course you know your environment better than we can ever do, no wonder non-js talk was not of interest.

>But such usability talk is a bit off topic.

I don't agree, if you really want your app to work, this is the most important thing ... still, enuf dogma.

All the same, if you have a good picture of how far in the future (or the past) that the majority of dates are being picked, then you could pre-select those input boxes, let say the month and the year - and leave the day as free-form.

Using the same ideal - I hacked around the date boxes used in PhpMyAdmin and they work a treat, pick a date from a pop up box. Godsend.

Date from db? You should read about the mysql format_date() function.

Get the date out of your db in the format you want in the first place.

Gd Luck

[hessodreamy]

Date from db? You should read about the mysql format_date() function.

Normally I would, but in this case I'm going to need to order some dates AFTER the query, which is just easier to do in its native form YY-mm-dd.

[Cups]

But such usability talk is a bit off topic.

You were right there, sorry.