profile date fields not importing correctly

I have a date cell formated as "d-mmm-yy" and it seems to come through just fine.

I am unable to get a profile field that is a date to work. I have an expiration date in the old system I'm importing. I've tried these formats:

31-12-2010
01-September-2008
"Mon, 01 Sep 2008 00:00:00 UTC"

The imports run without any warnings, but the profile_expire_date is still empty so that when I try to view the data it defaults to today's date.

What is the proper date format? Here a typical line of my file:

First,Last,password,31-12-2010

I never tried but I think the default date in Drupal looks like
2004-02-12T15:19:21+00:00

but I'm not sure...
just try to put some dates from one of the rows in the .csv and see if the date keeps on the system.

I think i found a bug in _user_import_save_profile function. Problem is that profile module save date fields in serialized format so its not possible to just save dates like plain texts. I have modified _user_import_save_profile function to work correctly with date fields (although not sure is this the best way):

function _user_import_save_profile($field, $uid, $value) {
    // BEGIN CHANGE
    // It seems that drupal saves date profile fields in serialized format.
    $type = db_result(db_query("SELECT type FROM {profile_fields} WHERE fid = %d", $field));
    if ($type == 'date' && $value != '') {
      // Assuming MM/DD/YYYY format.
      list($month, $day, $year) = split('/', $value);
      $value = serialize( array('month' => $month, 'day' => $day, 'year' => $year) );
    }
    // END CHANGE

    $profile = db_query("INSERT INTO {profile_values} (fid,uid,value) VALUES(%d,%d,'%s')", $field, $uid, $value);
    return;
}

For more info take a look to http://api.drupal.org/api/function/profile_save_profile/5 and http://api.drupal.org/api/function/_profile_field_serialize/5

I have experienced the smae problems trying to import a date field and believe you have hit the nail right on the head with your code change.

For anyone (like me) preparing their data for import using Excel, remember to format the date fields as 'm/d/yyyy' before saving as CSV and importing. If you leave the formatting at the default 'mm/d/yyyy' or 'mm/dd/yyyy' you will end up with leading zeroes on at least the month field for months up to September and they will not import properly (defaulting instead to January).

Have applied the modifications in #4 to the user_import.module and formatted as m/d/yyyy as suggested in #5 and this works! Thanks very much, I've spent way to long trying to solve this problem and the suggestions in #1 to format the date as d-mmm-yy does NOT work. Wonder if this should be a formal patch?

Good "patch" in #4 for this wonder module.
For other date formats, like dd/M/yyyy (in my case), simply change the order of list and serialized array.
Dont forget the "M". "MM" doesnt works.

*********ADDED LATER***********

My imported fields are repeated. Even if I import in M/dd/yyyy format (not a date problem). I identify this problem in view module, in a list of users, and check in the database table. In every user imported, only in 3 fields of profile (of 10) information are included, but the same fields are included with empty values (repeated). The other fields are empty, and are OK. After a look in the profile over an administration interface and SAVING, the problem are solved, with the empty duplicated fields deleted by drupal. I will dont do this with 1200 included users........................

Any suggestion?

Regards,

Solved in here:

http://drupal.org/node/174322

There's one comment at the end that suggests to comment one line, and you will not have any duplicate field.

Cheers

Man,

You are the best. Kill my headache!!!

Thanks a lot.

regards,

You're welcome :)

Hi all,
First of all, the version of user_import module that i use is: user_import-5.x-2.8.tar.gz
For the date format, I have tried suggestion in #4, but i think this code need to implement more in the profile_user_import_save_profile function, which is in profile.inc

I implement like the one below:

function profile_user_import_save_profile($field, $uid, $value, $updated, $update_setting, &$data) {   

	// when the profile field is displayed on the registration form an empty value is automatically saved by the Profile module
	$exists = db_result(db_query("SELECT value FROM {profile_values} WHERE fid = %d AND uid = %d LIMIT 1", $field->fid, $uid));

if($field->type == "date"){
	  // Assuming MM/DD/YYYY format.
      list($month, $day, $year) = split('/', $value);
      $value = serialize( array('month' => $month, 'day' => $day, 'year' => $year) );
	} 

	if ($updated) {
		switch ($update_setting) {
			case UPDATE_NONE: 
				return;
				
			case UPDATE_ADD:
        if (empty($value) || (!empty($exists) && $exists != '')) return;
 
			case UPDATE_REPLACE:

				if (empty($value) && $update_setting == UPDATE_REPLACE) {
					
					db_query("DELETE FROM {profile_values} WHERE fid = %d AND uid = %d", $field->fid, $uid);
					unset($data[$field->name]);
					return;
				}

				if ((empty($exists) && $exists != '') || $exists === FALSE) { 
					db_query("INSERT INTO {profile_values} (fid,uid,value) VALUES(%d,%d,'%s')", $field->fid, $uid, $value);
				}
				else { 
					db_query("UPDATE {profile_values} SET value = '%s' WHERE fid = %d AND uid = %d LIMIT 1", $value, $field->fid, $uid);	
				}
				
				$data[$field->name] = $value; 
				return;
		} 

	}
	else {

		if (empty($value)) return;
 
		if ((empty($exists) && $exists != '') || $exists === FALSE) {  
			db_query("INSERT INTO {profile_values} (fid,uid,value) VALUES(%d,%d,'%s')", $field->fid, $uid, $value);
		}
		else {  
			db_query("UPDATE {profile_values} SET value = '%s' WHERE fid = %d AND uid = %d LIMIT 1", $value, $field->fid, $uid);
			$data[$field->name] = $value;
		}
	}

	return;   
}

And also need some little changes in function profile_user_import_after_save, which is like the one below:

function profile_user_import_after_save($settings, $account, $password, $fields, $updated, $update_setting_per_module) {

	// get all fields
  $profile_fields = profile_get_fields();
	$data = $old_data = unserialize($account->data);

  foreach ($profile_fields as $field) {
		profile_user_import_save_profile($field, $account->uid, $fields['profile'][$field->fid][0], $updated, $update_setting_per_module['profile'], $data);
	}
	
	// data column in the	user table needs to be updated
	if ($data != $old_data) {   
		//db_query("UPDATE {users} SET data = '%s' WHERE uid = %d LIMIT 1", serialize($data), $account->uid);
db_query("UPDATE {users} SET data = '%s' WHERE uid = %d LIMIT 1", 'a:0:{}', $account->uid);
	} 

  return;
}

Note that, without changes in function profile_user_import_after_save, your date will still not display properly, even though the value in table profile_values already in a form of serialized array.

So the correct date format should be: MM/DD/YYYY

Thanks.

I have created a patch with the code in #12.

It also adds a select option on the configure page (admin/user/user_import/configure) that allows you to select a date format to use (more date format options can be added if required).
The option only appears if the profile module is enabled.

The patch is against 5.x-2.8 and seems to work correctly in my testing.

Renaming to properly describe the issue

Here is a 6 version of this patch.

I have not been able to test it yet, I just did a quick port of the 5 patch as all the changed code seems to be the same across both versions.

I have marked #449466: date field does not seem to work as a duplicate of this issue.

I have made a little change to these patches as I was having problems with days and months with a leading zero.

The patch now strips leading zeros from the day and month parts and that problem is fixed.

Hi,

Just one small typo fix affecting YYYY/MM/DD users:

-+ else if ($date_format == 'YYYY/MM/DD/') {
++ else if ($date_format == 'YYYY/MM/DD') {

Cheers,

Paul

Oops, thanks for fixing that.

Can you give some more information like a date that doesn't go in or something?

I've attached a sample file I tried to upload. The dates import correctly if I specify a text field as the destination but then they need transforming to be of any use.

I was able to successfully import your file in with date data going into a date field.

I am using Drupal 5.12 and User import 5.x-2.8
The field I am importing into is a date field not a text field
On admin/user/user_import/configure for Date field format: I have selected DD/MM/YYYY

Is there anything else you can think of about your set up that might affect this import?

Only that I'm using Drupal 6.12 and User Import 6.x-1.2.

That would explain why it does not work as expected. This patch is for Drupal 5 and it is rare that a module is so similar from D5 to D6 that a patch will work for both.

And seeing as this patch will more likely be accepted with a 6 version as well I'll change the issue.

This patch will have to be ported to D6.

I won't be able to work on porting it to 6 any time soon though so if anyone else wants to that would be great.

It would be nice, if this could be fixed for the D6 version of the module.
For importing users with a field "birthday" I used this "workaround":
1. Open the CSV file with open office
2. Insert a new column "birthday new"
3. Enter the following formula (this is for the german OO version!)

="a:3:{s:3:" & ZEICHEN(34) & "day" & ZEICHEN(34) & ";s:" & LÄNGE(TAG(BU2))&":"&ZEICHEN(34) &TAG(BU2)&ZEICHEN(34)&";s:5:"&ZEICHEN(34)&"month"&ZEICHEN(34)&";s:"&LÄNGE(MONAT(BU2)) &":"&ZEICHEN(34)&MONAT(BU2)&ZEICHEN(34)&";s:4:"&ZEICHEN(34)&"year"&ZEICHEN(34)&";s:" &LÄNGE(JAHR(BU2))&":"&ZEICHEN(34)&JAHR(BU2)&ZEICHEN(34)&";}"

4. Copy the formula down into each row
5. Repeat steps 1 to 4 if you have more date fields
6. Import the CSV file

The formula converts a date field entry like "dd.mm.yyyy" to something like this
a:3:{s:3:"day";s:2:"31";s:5:"month";s:1:"3";s:4:"year";s:4:"2000";}
Thats what the profile field expects.

Dumb question.

How do I implement the patch in #19 for the latest Drupal 6 install?

It's not cut and paste. Is there a script i run in install it?

Thanks,

Al

Reading back through this issue some of the conversation doesn't make much sense (my fault).

There is already a patch for drupal 6 in #19

So is the consensus that the D6 patch in #19 doesn't work properly? I'll test soon if I get a chance.

@ozguy:
All the info you need for making or applying patches can be found here - http://drupal.org/patch

Thanks for your advice Justin. I followed the patch howto, and also watched the video on patching, however had issues with running the patch.

I copied the patch contents for Drupal 6 (I'm using Drupal 6.14 BTW) and saved the file to the "/var/www/html/drupal/sites/all/modules" directory and tried to run it with "patch < user_import.patch", but it seems to want different directories "user_import6 and user_import6_old", and returns the "file to patch" request. I renamed the directory user_import6, but it still had issues finding the files.

I filled the values manually, and it seemed to work, but it finally failed with a hunk error:

patch unexpectedly ends in middle of line
Hunk #2 succeeded at 247 with fuzz 1.

I ran the import after the patch ran, and date fields were corrupted.

Any advice?

Thanks in advance,

Al

Here are the patch run messages:

[root@Drupal6 modules]# patch < user_import.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/supported/profile.inc user_import6/supported/profile.inc
|--- user_import6_old/supported/profile.inc 2009-04-05 02:24:18.000000000 +1000
|+++ supported/profile.inc 2009-05-21 11:35:39.000000000 +1000
--------------------------
File to patch: user_import6/supported/profile.inc
patching file user_import6/supported/profile.inc
Reversed (or previously applied) patch detected! Assume -R? [n]
[root@Drupal6 modules]# patch < user_import.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/supported/profile.inc user_import6/supported/profile.inc
|--- user_import6_old/supported/profile.inc 2009-04-05 02:24:18.000000000 +1000
|+++ supported/profile.inc 2009-05-21 11:35:39.000000000 +1000
--------------------------
File to patch: user_import6/supported/profile.inc
patching file user_import6/supported/profile.inc
Reversed (or previously applied) patch detected! Assume -R? [n] y
can't find file to patch at input line 133
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/user_import.install user_import6/user_import.install
|--- user_import6_old/user_import.install 2009-03-25 22:31:09.000000000 +1100
|+++ user_import.install 2009-05-21 10:05:51.000000000 +1000
--------------------------
File to patch:
[root@Drupal6 modules]# patch < user_import.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/supported/profile.inc user_import6/supported/profile.inc
|--- user_import6_old/supported/profile.inc 2009-04-05 02:24:18.000000000 +1000
|+++ supported/profile.inc 2009-05-21 11:35:39.000000000 +1000
--------------------------
File to patch: user_import6/supported/profile.inc
patching file user_import6/supported/profile.inc
can't find file to patch at input line 133
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/user_import.install user_import6/user_import.install
|--- user_import6_old/user_import.install 2009-03-25 22:31:09.000000000 +1100
|+++ user_import.install 2009-05-21 10:05:51.000000000 +1000
--------------------------
File to patch: user_import6/user_import.install
patching file user_import6/user_import.install
can't find file to patch at input line 153
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rupN user_import6_old/user_import.module user_import6/user_import.module
|--- user_import6_old/user_import.module 2009-03-22 09:32:42.000000000 +1100
|+++ user_import.module 2009-05-21 10:15:38.000000000 +1000
--------------------------
File to patch: user_import6/user_import.module
patching file user_import6/user_import.module
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 247 with fuzz 1.

@ozguy,

Your problem is probably having the patch in the sites/all/modules folder.

Most patches are made to be run from the modules folder itself. So you would put it in the sites/all/modules/user_import folder and then run with

patch -p0 < user_import_profile_date_field_D6_3.patch

Justin,

Over all the D6 patch seems to work, as it does import the date fields into the fields correctly, however is also seems to store the char value "NULL" in the field if "NULL" is placed in the contents of the field.

The display part in the user page (www.site.com/users/xxxxyyyy) that seems to be messed up now.

It did work better running it as you recommended, however the hunk error sill continues:

[root@Drupal6 modules]# patch -p0 < user_import.patch
patching file user_import6_old/supported/profile.inc
patching file user_import6_old/user_import.install
patching file user_import6_old/user_import.module
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 247 with fuzz 1.

Either way the user import process runs without errors, and looking at the profile_values table reveals that the dates seem to have been imported correctly, showing exactly as the data imported via format mm/d/yyyy.

However reviewing the user data shows the date fields to be corrupted (dsiplaying 00/00/N) as well as displaying the following screen errors:

messages:warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.
warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal-6.14/includes/form.inc on line 1726.

Which seems to match the date fields which had a value of "NULL".

I assume means that the date format that the user information display code is looking for the data is a different format, even though the fields are set up as dates.

What value should I place in the date fields if there is no value? Null does not seem to work (actually stored as "NULL" in the table field), the current days date is displayed if no date is stored in that field.

Once again, thanks for your help Justin.

Alan

I have tested the D6 patch in #19 again (now with Drupal 6.15 & user_import 6.x-2.3) and it works for me

[EDIT] I posted this before I saw post #33 so this is not in response to that post.

I just applied the patch in #19 to user_import 6.x-2.3 and it applied cleanly so your patch file might be messed up or you are not using a clean version of user_import or the patch is not being applied correctly or something.

Aside from that, hunk succeeding with fuzz isn't a great cause for concern but I would investigate the "patch unexpectedly ends in middle of line" part. It would be best if that wasn't there when you applied the patch.

When I get a bit of spare time I'll have a look into the NULL value issue.
If you can give me a csv file with a few rows that cause problems I can have a better look.

Justin,

I've attached the CSV file as an XLS file as CSV file extension is not up loadable.

I'm wondering if the way I copied the patch into the system caused the error. I opened the patch to a new browser page, and copied and pasted all contents into the server patch file via SSH. The file looks fine with no truncation or mangled lines, but maybe that was the cause. I'll try again later.

I'll be upgrading to Drupal 6.15 tonight and will also re-install the user_import and re-test the patch then.

Al

Thanks for the file, I'll test it when I get a few spare minutes.

Easiest way to get the patches is to right click the link and save as. Then you'll get the actual file.

Did you get a chance to check it out Justin?

I'm a week away from going live, and still can't get around the issues no matter what module options I try.

The data loads fine into the DB, but the display in the user profile is shot.

Even worse, the date fields that have no values show as the current day in the users profile. Seems there's no way to set a null default, or be able to set it to null once the user has been created. Painful.

Thanks for your help so far. It's been greatly appreciated.

Al

Sorry, I haven't got back to this yet. I blame christmas.

I'll have a look when I get home today.

I posted a reply to this yesterday but I don't know where it went, sorry.

I have had a look at your problem and the issue is that the date field won't accept the text NULL as a value.
If you change null to a blank cell in your spreadsheet you will stop the gmmktime() warnings.
But then you will still have 00/00/ for the dates and when that profile is next saved and no dates have been entered it will be 01/01/1900.

The problem seems to be that profile date fields just aren't really very good. Profile fields in general are not very flexible.
Profile date fields can't handle not having an empty date.
This means you would have to give fields without dates the value 0/01/1900 or something.

If this is no good to you another possible option might be to do the following:
* Using the content profile module along with the cck and date modules you could create a profile content type.
* Then you could use user_import to import the basic user details from your spreadsheet
* Then using the node import module you could import the extra profile fields from the spreadsheet into your profile content type. From memory I think all you need to do is set the author of the profile node to the username of the user it belongs to and it will link that node to the user. I think it also allows you to make the profile node a tab on the users profile.

This way the use of date & node_import should give you better flexibility.

Thanks for the feedback and advice.

I have tried the content profile, along with CCK, and date and phone modules, which are a far improvement over the standard user profile, especially in terms of data normalization, as well as data validation. Unfortunately the Non-for-profit site goes live this coming Wednesday, and my time has run out, so I must stick with the user profile for now.

I did do some further checking to determine why the user profile page does not like the date format I was using. I added a user manually, adding all fields including the dates. When I looked in the database (profile_values) I found that the dates were being stored as:
a:3:{s:5:"month";s:1:"9";s:3:"day";s:2:"10";s:4:"year";s:4:"1990";} for a date of 9/10/1990.

So I thought, what the heck, and I wrote a perl script that converts all dates in the user import input file into that exact date format, and uploaded all of the data perfectly. I happily noticed that the date fields looked exactly the same as the manually added dates for a new user in the database table.

Got a bit of a shock when I went to the imported users profile page and saw these errors on the page (one for each date field on the page):
# warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal/includes/form.inc on line 1726.
# warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal/includes/form.inc on line 1726.
# warning: gmmktime() expects parameter 4 to be long, string given in /var/www/html/drupal/includes/form.inc on line 1726.

I'm using drupal 6.14, and the form.inc include file has the following code at the line mentioned:

1722 /**
1723 * Helper function for usage with drupal_map_assoc to display month names.
1724 */
1725 function map_month($month) {
1726 return format_date(gmmktime(0, 0, 0, $month, 2, 1970), 'custom', 'M', 0);
1727 }

I was quite stunned at this. All of the date values looked like this on the page : "00/00/a". (it looked like 00/00/N when I imported the date as mm/dd/yyyy earlier)

If I go into edit mode, it shows all dates as "Jan/1/1900", a default in case of error i guess.

What I can only assume is that while the dates in the profile_value are identical regardless of how the data was added (via manually creating a user, or upload via user import), there is some other processing done behind the "add user/user edit" page that either places the date in other DB table fields as well, or somehow sets a data trigger, or something.

And then we get the date field default values in the user edit pages of the current, with no way to set them to NULL.......Don't get me going on that.......

Anyhoo, What do you think guru's? How can identical data in a date field be handled differently on a display page depending on how the data was added? Riddle me that one batman.......

Thanks in advance for any further advice or info,

Al

Well without having the time to look into it properly:

Parameter 4 for gmmktime() is month so that error means the function is being passed a sting instead of a number for the month value.
To see what is being passed into this function you can use the devel module and use the dpm() or dd() function in form.inc to check the values being passed into the gmmktime() function.

I don't think drupal would have any knowledge of how the data was entered so if the data in the database is the same then it should display the same. I would be leaning towards there being something different in the database data between the dates that work and the dates that look like "00/00/a".

Thanks for the advice.

Which devel module in particular should I use Agileware? Profile is part of the Drupal core which I enabled.

I can assure you that I've checked the date fields, one character at a time, and have even copied a manually added date from the database to all of the dates in an imported users DB entries (before viewing or editing the profile), and the error appears. Really weird.

Al

Devel module
It comes with a few other modules but you shouldn't need any of them.
If you enable devel it has functions you can use that help with debugging.
dpm($var); will print the value of $var to the screen. You can put constants, variables or whatever in as $var - http://api.lullabot.com/dpm
It is similar (but better) to php's print_r
dd($var); Does the same as dpm but instead of printing to screen it will print to a file (it will create one if it isn't there) called drupal_debug.txt in whatever your site specifies as it's temp folder. - http://api.lullabot.com/dd

They are both helpful for telling you what value a variable holds at a certain time.
There are other useful things in there too but those are the ones I use most often.

I've installed many modules in the past for this web site, but I must say I'm a bit perplexed that I cannot get the devel module up and running.

I downloaded it, installed it in the site/all/modules directory, set it's permission the same as the other modules, made every file in ithe module executable, yet I still cannot see it in the modules page to enable it. I even moved it to the core module directory. same result.

Can't see it in the modules list to enable it. The system is out to get me I'm sure of it.....

The rest of the site is fully functional, so I feel good about that.

Thanks for your advice so far mate. I'll try to keep banging away at it. I hate to lose.

Al

Thanks for working on a patch. I was wondering if you considered the date_parse() function to reduce the need for pre-formatting the input data (http://www.php.net/manual/en/function.date-parse.php).
It automatically tries to recognize different standard date formats.

Returns array with information about the parsed date on success or FALSE on failure.

Example #1 A date_parse() example

print_r(date_parse("2006-12-12 10:00:00.5"));

The above example will output:

Array
(
[year] => 2006
[month] => 12
[day] => 12
[hour] => 10
[minute] => 0
[second] => 0
[fraction] => 0.5
[warning_count] => 0
[warnings] => Array()
[error_count] => 0
[errors] => Array()
[is_localtime] =>
)

Apologies that I don't have time right now to put it into another patch.

Oops - that function's only in PHP5. Should be able to get the same functionality combining strototime() and getdate(), which are both PHP4 compatible.

Something like:

$date_array = getdate(strtotime($import_field));

// then, add the parts to the $user object, and save it.

Will the patch in #19 work with v2.3?

subscribing

I'm having this same issue right now. I imported the dates using this syntax: a:3:{s:5:"month";s:1:"9";s:3:"day";s:2:"10";s:4:"year";s:4:"1990";}.

I get the following error as well:
warning: gmmktime() expects parameter 4 to be long, string given in C:\wamp\www\drupal\includes\form.inc on line 1728.

When browsing through the database I noticed that the date is not only stored in the profile_values table, but also in the users table in the data field. When setting the date manually this isn't the case.

I changed this code on line 84 in user_import\supported\profile.inc:

$data[$field->name] = $value;
return;

to:

unset($data[$field->name]);
return;

This causes the field only to be written to the profile table and it seems to have solved the error.

subscribe

I noticed in the patch above, it uses $update_setting_per_module which contains an array of values for roles, profiles, password, instead of $update_setting which only amounts to either true or false.

In a patch to allow user_import to be compatible with shared_email http://drupal.org/node/497652#comment-3328332

I do something similar as I need the array of values rather than just true/false

+1 for date_parse however date_parse thinks that non US dates using a forward slash are US dates, so that doesn't work. Ultimately I'd like to be able to enter a custom format. The spreadsheet I'm trying to parse has D M j G:i:s \G\M\TO Y!

Having said this (#54) I am extremely happy about this patch and think it should be committed! You should probably also be able to select the date format per import as well as setting the default.

Any headway made on this recently?
I'm trying the D6 patch from #19 on release user_import 6.x-2.4

Update

The import succeeds — but I noticed in the database, the date was saved as text
"1/2/2011" - instead of the UTC format the date field requires "2011-02-01T00:00:00"

How can I fix this?

Update 2
Found a solution — the CSV file must have the date in the format: "2011-2-1", with dashes and not "/" slashes.

There is a file with applied patch here (and some other changes)
http://www.drupaldump.com/user-import-patched-date-import-working

When i started using drupal i also hated applying patches and in windows env. it was always some problems bugs wrong versions etc. Wish people would just upload patched version also with a patch just for neewbies to have it easier.

Added to 6.x-3.0-beta2.

Needs testing.