Handle profile.module 'date' field sync

I don't have separate patch for this issue. My patch fixes it and adds support for multivalue attributes. It still should be tested a bit, but it works on my installation.

Unless I missed something when implementing this patch, it does work with date fields but there's a problem viewing synced dates within the profiles.

The dropdowns in the date field (within the profile) seem to store dates as both 1 and 2 digit months and days. So for example, January gets stored as '1' and not '01'. So the problem is that for June 7, 1974, it's stored properly in ldap as 19740607 and in drupal as 06 07 1974 (using this patch) which leads to the dropdowns showing Jan 1 1974 (see image attachment). Submitting any other changes to the profile (without correcting the listed month and day in the dropdowns) would then cause the profile to be saved with the date of jan. 1 1974 (which then pushes that to LDAP). When I checked the mysql database, I see this:

a:3:{s:5:"month";s:2:"06";s:3:"day";s:2:"07";s:4:"year";s:4:"1974";}

So the date is being stored but for the dropdowns to show properly, that same data would need to be stored as the following:

a:3:{s:5:"month";s:1:"6";s:3:"day";s:1:"7";s:4:"year";s:4:"1974";}

I'm afraid I'm a beginner with php so I don't know how to make this happen.

Thanks.
Larry

I think I figured out the date problem I was having. I did some research on various php functions (like I said I'm still a beginner) and I discovered ltrim. I modified 2 lines in this patch (lines 48 and 49) as follows:

$writeout[$field]['month'] = substr($entry[strtolower($ldap_drupal_reverse_mappings[$key])][0], 4, 2);
$writeout[$field]['day'] = substr($entry[strtolower($ldap_drupal_reverse_mappings[$key])][0], 6, 2);

became

$writeout[$field]['month'] = ltrim(substr($entry[strtolower($ldap_drupal_reverse_mappings[$key])][0], 4, 2),0);
$writeout[$field]['day'] = ltrim(substr($entry[strtolower($ldap_drupal_reverse_mappings[$key])][0], 6, 2),0);

That removes the 0 from those months and days that need to be stored as single digits (i.e. 07 becomes 7 when stored in the date array). So far everything seems to be working well!

Another variant to add the "date" fieldtype for the ldap_integration/ldapdata.conf.php configuration file.
The LDAP GeneralizedTime format is used to store the date in LDAP.

svn diff against dev version is attached

I'm still experiencing this error using date fields in 6.x-1.0beta1.

Any chance we can get one of these patches added to the next beta?

Thank you!
- Vince

Here's an updated patch that will do the Right Thing (TM) when it comes to synchronizing 'date' fields between LDAP and profile.module (for things like birthdays). It uses some code from the previous patches but ONLY supports profile dates (I think the other patches allowed drupal account fields or rw LDAP access). Let me know if anybody needs that functionality back and I will roll the patch again with those features included.

It is worth noting that this patch stores the date in MySQL as a serialized array and in LDAP as a "standard" integer (not really sure how standard it really is, shadowAccount uses this). It could be easily modified to do a proper GeneralizedTime syntax if needed.

Also, I'll go ahead and assign this issue to me unless there are any objections.