Different default value

The question is whether CCK will be doing that as a core function, which is what was originally discussed. If so, it would be redundant (and wrong) to do it in the date module. IMHO it seems like something that CCK should do for all fields. At any rate, I'm holding off until it becomes clear what CCK is going to do. If JonBob puts it into CCK, there is nothing to be done here. If he commits the patches that put that capability into each individual field module, then I need to add it to the date module.

Waiting to see...

There is working going on to define the core content module handling for default values. Once that gets nailed down, I'll come back and make the necessary adjustments to the date module.

Bumping now that this is getting close...

Concerned that the types of valid date values will be restricted, we should certainly allow all valid php str_to_time dates as defaults. I have in mind, for instance, the phrase "next tuesday" as showing up as a default value upon presentation of the CCK form to the end user. The user can leave it as is, and str_to_time will translate it to the date of next Tuesday.

It appears as the original topic for the CCK module has now been closed. Does this mean that default dates should be possible in the module now?

At this point, the Date module is handling its own default values since the default handling by the content module won't work right with dates. What is not done yet is to allow the admin to set it. Currently it defaults to blank for non-required fields and the current date for required fields. Need to add a field or widget setting to allow the admin to have more control over that, but I'm not going to have time to work on this right now.

I may report another issue for this but I'm curious if this is related.

When I set a date field to required, it fills out the default date as the current date but when granularity is set to year, month and day the default current date appears to be delayed. For example, when it's 2am here, the default date is still the day before.

I know it's not possible to set the timezone unless you have hours in the granularity but shouldn't it default to the sites timezone as well? I'm not entirely sure how this works but this is seems to be a lacking feature.

Subscribing since I need the functionality for a content review date so I can default it to 12 months in the future using a bit of php.

As per the conversation with KarenS today, we came to the conclusion that being able to set the default date based on now+diff would cover 90% of cases.

Also being able to base the default on another field + diff would also come in handy.

Just wondering where we are on this?

I would really like to be able to ignore blank dates within a view, but as that seems unlikely this seems like my best bet! What I want is to be able to set the From: date to be today and the To: date to be something like 3 months away. Is this possible whit what's been done so far?

Thanks
Andy

IF anyone else is desperate for a quick fix to this problem, I found the simplest way was to add a switch to the date.inc file that changed the default value depending upon the lable. I am using jscalendar so just hacked that section so it now reads:

  if ($required && !$blank_default && $params['value'] == '') {
    switch ($format) {
    case(DATE_UNIX):
      $now = date_gmadj_zone(time());
      break;
    default:
      $now = date_unix2iso(date_gmadj_zone(time()));
	}
	switch ($label){
		case("Start Date"):
			switch ($format) {
				case(DATE_UNIX):
				$now = date_gmadj_zone(time());
				break;
			default:
				$now = date_unix2iso(date_gmadj_zone(time()));
			}
		break;
		case("End Date"):
			switch ($format) {
				case(DATE_UNIX):
				$now = date_gmadj_zone(strtotime("+6 months"));
				break;
			default:
				$now = date_unix2iso(date_gmadj_zone(strtotime("+6 months")));
				break;
		}
	}
	
    date_set_date($date, $now, $timezone_out, 'local', $format);
  }

If there is a nicer/proper way to do this please let me know, but this will tide me over till then!

Cheers
Andy

This feature is in the HEAD version of the date module now. That version is not yet completely functional, so don't try to use it until I create a 5.2 branch, but once you see a 5.2 branch you can try it out.