Upgrade Date API integration to work with Date 2 API

I'm marking this as critical as Date 1 is supported, but no longer recommended.

I don't have a lot of time to work on this in the next few weeks. I might be able to by the middle of December. Patches will be gladly accepted and reviewed!

re #1: use strtotime() instead of date_iso2unix -- No, definitely not. See #336255: CCK datestamp fields totally broken and fields without timezone handling mostly broken for the hell that path leads you to. ;) No, the right way to support Date2 is to actually use the DateAPI as intended, and that means using date objects for everything, and the various date manipulation and comparison functions those objects support. You should never use strtotime() directly, since that won't support all the various configuration options that DateAPI allows (e.g. datestamp fields, the various forms of timezone handling, etc).

It's possible to backport date_show_value() function?
I've tried to copy original function, but it should work normally, or there is some deepest problem with that?
See discussion here: http://drupal.org/node/343218

Subscribing...

I'm having the same issue.

Subscribing.

This module would perfect for 2 current acute projects with tight deadlines - if it only worked with Date 2 Api. I'll try kenorb's solution.

I got it to work, but probably not in the best way, as I don't exactly use the Date Api but direct PHP date handling. First I tried using Date Api, but it seemed unnecessarily complex and confusing. Also, it would only work with either the older Date Api OR the newer version. It seems some functions require PHP 5.1, but so does Date Api 2 (but "Date_PHP4"-module takes care of that).

So this is not really a good patch, but a temporary hack that you can use while waiting for someone who thoroughly understands the Date Api to make a better fix.

L19, as suggested by thetrickyt. "date.inc" => "date_api.module". I would think this is unneeded as date_api.module should be always loaded.

	  require_once(drupal_get_path('module', 'date_api') .'/date_api.module');

Formatting the date for the error message without date_iso2unix(). Changed this..

      if (strpos($date_field, 'field_', 0) === 0) {
        $start = format_date(date_iso2unix($conflicting_node->{$date_field}[0]['value']));
        $end   = format_date(date_iso2unix($conflicting_node->{$date_field}[0]['value2']));

..to this:

      if (strpos($date_field, 'field_', 0) === 0) {
		 $start_date = date_make_date($conflicting_node->{$date_field}[0]['value'], 'GMT', DATE_ISO);
		 $start_date->setTimezone(timezone_open(date_default_timezone_get()));

		 $end_date = date_make_date($conflicting_node->{$date_field}[0]['value2'], 'GMT', DATE_ISO);
		 $end_date->setTimezone(timezone_open(date_default_timezone_get()));
		  
		 if($start_date->format('d.m.Y') == $end_date->format('d.m.Y')){
 			 $endformat = 'H:i';
		 }else{
			 $endformat = 'd.m.Y H:i';
		 }

	     $start = $start_date->format('d.m.Y H:i');		 
	     $end = $end_date->format($endformat);
		}

A bit additional code, as I also added a small improvement: only show the time of the to-date value, if the to-date day and start date are the same. Not all want to use 'd.m.Y H:i' as the date-format, maybe it should go through t() -- or use the intended Api? I still used date_make_date()-wrapper function from the Date Api, could have used date_create() directly.

Anyway in Date Api 2 "date_make_date()"-parameters have changed, like this:

function date_make_date($value = '', $timezone = 'GMT', $type = 'db', $format = DATE_ISO) {

is now:

function date_make_date($date, $timezone = NULL, $type = DATE_DATETIME) {

Confusing indeed, $type is still the 3rd param, but it's actually the format now. So.. I updated the it in a few places. The changed functions look like this:

function _resource_conflict_overlaps_from_date($date_start, $date_end) {
 $start = date_make_date($date_start, 'GMT', DATE_ISO);
 $end = date_make_date($date_end, 'GMT', DATE_ISO);
 return _resource_conflict_get_overlaps($start, $end);
}

function _resource_conflict_overlaps_from_event($event_start, $event_end) {
 $start = date_make_date($event_start, 'GMT', DATE_UNIX);
  $end = date_make_date($event_end, 'GMT', DATE_UNIX);
  return _resource_conflict_get_overlaps($start, $end);
}

After that I only had to change some "date_show_value($start, 'db', DATE_ISO);" to "$start->format(DATE_FORMAT_ISO);"

function _resource_conflict_get_overlaps($start, $end) {
  $date_start = date_show_value($start, 'db', DATE_ISO);
  $date_end = date_show_value($end, 'db', DATE_ISO);
  $event_start = date_show_value($start, 'db', DATE_UNIX);
  $event_end = date_show_value($end, 'db', DATE_UNIX);

To:

function _resource_conflict_get_overlaps($start, $end) {
  $date_start = $start->format(DATE_FORMAT_ISO);
  $date_end = $end->format(DATE_FORMAT_ISO);
  $event_start = $start->format(DATE_UNIX);
  $event_end = $end->format(DATE_UNIX);

In that last one there's no need to mess with timezones, as the values are not shown but used to compare the db values, which are all in UTC. Instead, using the sites timezone (a non UTC/GMT one) would actually result in wrong calculations.

More info about what's going on with the timezones and date-object:
http://fi2.php.net/manual/en/function.timezone-open.php
http://fi2.php.net/manual/en/function.date-create.php
http://fi2.php.net/manual/en/function.date-default-timezone-get.php <--- note, this function returns the global TimeZone setting, in my case "Europe/Helsinki" (GMT+2). I'm not sure if this is the site global timezone or the user specific one, but I assume this is set somewhere via the date module.

Are you working with Drupal 5 or 6?

Is someone willing to create a patch or a new version of this for both D5 and D6? I'd be willing to test out any new D6 version version of this module.

I'm working with Drupal 5 at the moment, not Drupal 6. The modifications I wrote seem to work fine in two of my current projects.

Unfortunately I'm not too familiar with the API changes between Drupal 5 and 6, and currently don't have the time either. If someone creates a Drupal 6 version, afaik the new Date API shouldn't be a problem if you add the same modifications in the following 3 functions:

function _resource_conflict_display_conflict_errors($node, $conflicting_nodes) {
...

function _resource_conflict_get_overlaps($start, $end) {
...

and

function _resource_conflict_overlaps_from_date($date_start, $date_end) {  // same for _resource_conflict_overlaps_from_event(...) 
...

In my current project I've added some other features too, like the option to limit the conflicts to only the same nodetype. Also, I created another small custom module which basically does the conflict check in reverse: a certain conflict may be required.

This can be used for example if you need to book a room for a patient and a doctor, and you always have to make sure the chosen doctor is at that particular time at work (and in the same place) as the patient.

@bibo: The two features you mention (limiting to the same node type) and requiring a conflict sound useful. Those could work nicely integrated with this module directly.

Signup supports both Date 1 and Date 2, so it is possible to do. It took quite a bit of effort though. Are there any other modules which only support Date 1 which are widely used? If not, I'm tempted to ditch Date 1 compatibility completely when I start on this.

FYI: signup's Date1 support is actually broken in some configurations. Date1 sucks. Karen doesn't support it at all anymore. If you want to do both, more power to you, but I think you'd be better off just porting directly to the full Date2 API and ditching Date1.

I've finally got around to porting this to Date 2 in preparation for a full Drupal 6 port. Here is a patch which works with Date 2 / Drupal 5 - can anyone test this and confirm that it works as expected?

And here is a patch against HEAD for Drupal 6, which implements Date 2 and fixes a few small bugs.

I haven't tested it much but it appears to have fixed the errors that I had on version 5 and works as expected. So far, I haven't been able to get this module to work on 6.10. I see no errors in my log, but it seems to never report any conflicts when tested.

Hi, I added the patch for Drupal 6.13 with Date 6.x-2.2 and it seems to work fine. If I find any problems I will let you know. What was the problem you had?

After applying patches to the 6.x head version of module, I don't see any settings for this module or a way to enable conflict checking. I have looked in the admin settings and under the date/nodereference content types for workflow settings. No luck. Any suggestions?

I've committed the patches for both Drupal 5 and Drupal 6.

@bomarmonk, I can't seem to replicate the same issue at the moment. Can you try again with the latest version from HEAD (or wait until the -dev tarball is updated), and if it's still a problem open a new issue? Thanks.