More work on repeating date computations and their tests. Adding repeating dates to CCK date fields now seems to be working, at least for the tested scenarios.

More rework of the date repeat rrule calculations; move lots of the code into .inc files since these are used often so no reason to parse all that code on every page.

A very very very very rough implementation of a repeating date in the CCK date module using Date Repeat. Still needs lots more work.

Fix PHP4 wrapper to be sure year is always padded to four digits.

Get tests working for PHP4 date_modify wrapper.

Standardize on date_make_date() instead of calling date_create() in some places so there is a central place to test the timezone and date values before creating the date.

Add method to customize the labeling of date parts to allow the label above the date part, inserted as the first item in the options array, or omitted.

Remove some functions that are not being used or move them so they are called only when needed to clean up the code.

More cleanup of PHP4 wrapper functions. We can get most things right except that there is no reliable way to get daylight savings time right in PHP4.

Rework the logic for handling the date timezone and converting from and to the db storage timezone. Finally realized the widget cannot do the timezone transformation, the widget must always be handling a date in the same timezone so validation and other processes can work correctly no matter what route the form takes. It will be up to the field, not the element, to transform the date from gmt to the local timezone when the date is retrieved from storage and back again before saving it.

This is the first of a series of updates to get this change implemented. Things are likely to be buggy untill all these changes are reworked and committed.

The Date Repeat API is mostly complete and can parse an iCal RRULE and return an array of dates that match the rule. Also added extensive simpletests on a variety of iCal RRULEs to test the logic. Not all iCal elements are included in this version, but the most common ones are. The API is not yet tied back into the Date module, so you can't do anything with it yet.

Reduce confustion by standardizing on use of 'month' instead of 'M' or 'mon', 'day' instead of 'D' or 'mday', etc, in granularity and date arrays.

Get rid of date_part_is_valid() which got too recursive and stick with just date_is_valid(); move hook_elements() to date_forms.inc so all element code is together for clarity and easier debugging; break up processing in Date module so each process is for a single element for consistency with the way things will work in the 6.x CCK port; more cleanup of the date processing and validation;

Very preliminary rewrite of Date API to become version 5.2. Not ready to be used yet! Still coming is rewrite of date and calendar module to use new API.