Allow user to specify duration (relative) or end time (absolute)

yes, this would be fantastic. if i have a chance and work on this, i'll post a patch. however, i haven't looked under the hood at date.module at all yet, so it might take me a while to get up to speed...

The end time is a new feature, so it's still pretty basic (and still being improved). However, this sounds like it would be a nice addition so if someone works up a patch I'd gladly look at it. Accepting a duration instead of an end date and calculating the end date is easy enough, the problem is figuring out how to work this into the UI. The input screen is already more cluttered than I like.

+1 this feature
... for UI, how about putting it in Advanced Input Options (collapsed fieldset) ?

Bumping this to HEAD. It won't go into the current version but maybe into the next one.

Subscribing.

^{benjamin, Agaric Design Collective}

I started to try to add this in and gave up for now. It actually is quite complicated to substitute in a completely different element to the form along with completely different processing steps, and to do that for each possible field/widget combination.

So this won't get done right away.

Not sure if this belongs here, in #130574: add a date_compare() function to DateAPI, or in its own issue, but what about a different approach for relative dates -- how about a separate "relative date" field that tracks a relative number of seconds, minutes, hours, days, weeks, etc, instead of an absolute date/time? I know the date computation functions might get all tricky with relative vs. absolute dates (although #130574 mentions a date_diff() function that sounds promising), but it seems like this would be very useful for a lot of reasons:

A) Events could have 2 separate date fields, an absolute start time and a relative duration, instead of absolute start and end times that have to be validated and manually updated. Of course, if there were enough date functions exposed and available through date API, you could convert from relative duration to absolute end time and back at will. If date_diff() does what it sounds like, then you'd only need a date_get_end($absolute_start, $relative_duration) function to compliment it. It'd be the inverse of date_diff(), so maybe call it "date_patch()" for short?. ;)

B) Issue nodes could have a relative "time estimate" field, and another relative "total hours spent on this issue" field. If comment_cck was smart enough, you could increment the time spent on an issue with each followup comment, or alter the total time estimate, just like you might change the priority or status.

... (there are probably lots of others, if I spent more time thinking about it).

(B) could be (poorly) approximated with a float # of hours for each field, but a relative date/time field would allow for much nicer UI widgets. However, I can't think of a good way to do (A) without having a first-class "relative date" field. Maybe (A) is a bad use-case for a totally separate relative date field, and events with start/end times should always be stored as 2 absolute dates, with the duration vs. end_time thing solely a widget/UI question, not a storage question. But, I'm sure (B) is valid, and I'd bet there are at least dozens of other use cases.

Should we discuss this here or in a whole new issue?

Thanks!
-Derek

I'd like to add a vote for a "duration" option when creating events --right now this is a very important feature for my (potential) site and one that will hold me back from implementing Drupal/Date/Calendar for the moment.

In a previous CMS calendar mod I've used the end-time was calculated by accepting an absolute date/time for start-time and a relative duration as dww suggested above. This seems like it would be simpler to implement and would make day views, as well as the iCal feed, more user friendly!

+1 Subscribing

@Dubs: http://3281d.com/2009/03/27/death-to-subscribe-comments ;)

Hi Dww,

Yes, very annoying - it would be great to be able to subscribe to a thread without having to add the "+1 comment". Thanks for drawing my attention to this project, and anyone else's if they're reading this.

Until that time, unfortunately, I will still put +1 subscribe to save me hours of searching for that post I once read.

Dubs

This issue is related to #104287: Time without a date feature
It is not really a DUPLICATE, but I think these two issues could have the same solution by creating a new field type of "Time Duration":

For events, allow the "To Date" to be replaced by a "Time Duration.". So, after selecting if the "To Date" is Never, Optional, or Required, the user then needs to select either 'Exact' or 'Relative'.

To simplify things, we could actually keep the exact "To Date" as is behind the scenes... the "Time Duration" is simply used to calculate the value of the "To Date." Thus, views logic remains the same... just a thought.
Thus, "To Date" really does not go away, it is just calculated using the "From Date" and "Time Duration"

Keep in mind that "Time Duration" should actually include years, months, weeks, days, hours, minutes, and seconds; just like an absolute time. Only difference is that "Time Duration" has no timezone considerations and granularity works in reverse.

See #497712: One date - start and end times, where I have a hack-ish patch (that is only tested with certain input widgets/other settings) that starts to implement something similar to the suggestion above:

It adds a new feature that lets the user pick a start date, start time, and end time, and then behind the scenes fills in the end date to match the start date.

It needs work to support the full range of UI choices/options in the Date module, but it might be a useful starting point for somebody.

In case anyone tries to implement this as an addition to Date, you might want to reuse lots of code from the Duration field. Especially the API parts.

What would also be terrific is if the "End date" was actually a different field than the "Start date", and they could just be displayed and edited together. That would make a similar "extender field" like added durations a bit easier.

+1

I am going to merge this issue with the one where penguin25 created a patch: #497712: One date - start and end times
I am marking that issue as duplicate so this issue can serve as the active issue. Further work should be done here.

Below are penguin25's comments about how the patch works. I edited it a bit for the LATEST provided patch, which is attached below.
***from penguin25***
Attached is a patch for date-6.x-2.3 of what I've managed to do so far.
When setting up a date field, you previously had "Never", "Required" and "Optional" as possible settings for the "To Date". With my updated patch, you now have "Required (time only)" and "Optional (time only)" as well. The "Time only" options effectively enable the patch.

I don't consider this patch to be a complete, full solution. Please read all of the following points before applying the patch:

1) It only changes the user interface. At the database level, the start and end times are both stored with the single date specified by the user. This maintains compatability with things like the Calendar module.

2) If you specify an end time that is earlier than the start time, then the end date is set to be the day after the start date (this effectively allows for the end time being after midnight).

3) Any exisiting "end dates" will be lost if you edit them after applying this patch. The time part of the end date will be preserved, but the date part will be set to either the start date, or start date + 1, as appropriate. You won't be able to get the original end date back.

4) ***FIXED*** The patch changes the behaviour of the Date module globally - after applying the patch, you'll always be presented with just date, start time and end time. It is not configurable on a per-content-type basis.

5) The patch only definitely works when choosing dates and times from a select list. I know it doesn't work with the date popup browser. Custom text formats are untested - it may or may not work with these.

6) The patch is not tested at all with repeating dates.

Comments/improvements are most welcome. I'm definitely interesting in fixing points 4, 5 and 6 in the list above, but I can't promise to do it immediately myself! All the code changes I've made are marked with a comment SHOW_TIME_ONLY_FOR_END_DATE, so it should be easy to spot them after applying the patch.

It also occurs to me that I haven't tested the patch at all on a system that makes use of timezones (my site uses "No timezone conversion" for all its date fields). So, the full list of features untested with this patch is:

- Choosing dates/times from any widget other than a select list.
- Using repeating/multiple dates per node.
- Using timezones.
***End penguin25 comments***

This looks like a good start to me, but I would prefer the time selection to be a time duration instead of selecting the "end time."
I think this would make timezone compatibility as well as the other issues easier to deal with.

Since somebody has shown some interest in my patch ;-), I'll add a few further comments:

1) Although it says it's for 2.3, it still works with 2.4. When applying it to 2.4, you get some warnings about line numbers not matching when it's applied, but it works fine.

2) With the latest version of my patch, the comment about all my code changes being marked is no longer true.

3) The way it works is to prevent the end date/month/year fields from being shown in the form used to edit the date, and then add them back in to the form data structure with the appropriate values before the form is processed. This is, I think, why it doesn't work with the date popup browser - different fields must be being used instead of the standard day/month/year fields. Presumably, though, the same trick could be applied to whatever fields are being used? And this logic extends to all the UI options that I haven't looked at yet.

4) Changing to "duration" instead of "end time" could, I think, be done by re-using the end time fields as a duration, and then adding the start time to them at the point where I currently copy the start date into the end date.

5) Any problems (if there are any) with using repeating/multiple dates will be because of the changing of the UI described above. I haven't looked into how repeating/multiple dates set up the fields in the editing form at all.

6) Any timezone related issues (if there are any) will be to do with whether the end date is chosen to be "start date" or "start date + 1". I haven't investigated whether or not the times have been adjusted for timezones at the point where I check for "start time < end time". So I think it might be possible to get the wrong end date being chosen if the end time is within "n" hours of midnight for a timezone that is "n" hours offset from GMT?

I've now added support for the pop-up date browser into my patch (attached), so the list of untested features is reduced to:

- Choosing dates/times from a custom text-entry widget.
- Using repeating/multiple dates per node.
- Using timezones.

I needed this same patch.

I was dreading trying to theme the date form element to remove the to date and putting it all on a single line...so thank you.

My vote is to get this into dates core.

Thanks penguin.

I've applied the patch in #19 to my DATE-2.4 module. I am trying to use the Calendar Popup with 15 minute increments on a required field.

Unfortulately when I submit I am getting this error from date_elements.inc

$element[$to_field]['#date_title'] = t('@field_name To date value #@delta', array('@field_name' => $field['widget']['label'], '@delta' => $delta + 1));

I tried to trace the code to figure out where it's going wrong, and it seems to be where ever the VALUE for 'value2' is setting set from form_values. It ends up being null instead of value1's date and values2's time.

I'll let you know if I find anything, but for now Im giving up.

Also found an issue when you're using mutiple dates (set to unlimited) with required To Time. If you add a blank second "date" and you leave it blank and submit, you are presented with an error to enter the hours and minutes.

How it usually works, is if a secondary date is optional (unlimited) and all the fields are left blank and you submit, it doesn't show on the new node. That's essentially how you delete an item.

This also causes issues when you edit an existing node, as the multiple date will present a blank new "date" which you can modify to have added to your node. Because the hours/minutes on the to_date are required....you can not simple hit, edit and save. You will need to append another date to your field.

FIX

This appears to be from an over zealous #required (or search and replace)

In your patch, this code is wrong I believe. It should be reverted to the original.

-    $element[$to_field]['#required'] = false;
+    $element[$to_field]['#required'] = preg_match('/^required/',$field['todate']);
     $element[$to_field]['#weight'] += .1;

I agree with the bug reports in comments 21 and 22, and the fix in comment 22 is correct - there is no need to change the #required value at that particular point (the change would have been valid if the original value was true, not false!). Thanks for tracking this down.

I've redone the whole patch with this fix, and attached it to this comment.

As part of investigating this, it appears that multiple dates do indeed work correctly with this patch (previously they were completely untested). Therefore the list of untested features is reduced slightly to:

- Choosing dates/times from a custom text-entry widget.
- Using repeating dates in a node (multiple dates are fine).
- Using timezones.

@Penguin25: Could you confirm that your updated patch resolves this error from showing up.

Unfortulately when I submit I am getting this error from date_elements.inc

$element[$to_field]['#date_title'] = t('@field_name To date value #@delta', array('@field_name' => $field['widget']['label'], '@delta' => $delta + 1));

Yes. I've tested by creating a field called "Test time" that is configured as follows (only seemingly relevant values listed):

- Widget type: Text field with date pop-up calendar
- Required: Yes
- Number of values: 2
- To date: Required (time only)

I then edit a node, and fill in Date, Start Time and End Time values for both fields in "Test time". With the previous version of the patch (comment 19), I get the following errors when trying to save, which seem to be related to the line of code you quote:

- Field Test time To date value #1 is required.
- Field Test time To date value #2 is required.

With the new patch (comment 23), these errors do not occur.

I tested this patch and it works great. It's applied againsnt 6.x-2.x-dev. Now everything works exactly how I'd expect.

Thanks for your work. This time thing is a wonderful addition to the date module.

First off let me say I'm also very much interested in this patch, as I work on a site where people from a variety of skills levels input events, and sometimes they forget to enter an end date, which defaults to some far off value. At that point the system assumes the event never ends, which in turn causes a variety of problems.

The only other option I'd like to see added is the ability to define a default duration, to even further reduce the possibility for user error.

+1 testing

This patch seems to work as intended, so thank you very much to penguin25!

Unfortunately, it also breaks compatibility with Resource Conflict (6.x-2.0) when "Required (time only)" is selected vice the previous "Required." Obviously, this is an issue with Resource Conflict polling the "To Date:" type in the Date field and only looking for "Required," which probably means a change to the Resource Conflict module is the easiest fix. However, since we're the ones patching Date, I was wondering if anyone could think of a way to modify this patch to help "fool" Resource Conflict into behaving the same as it would if "Required" was selected?

(The error message is: "This content type does not contain any suitable Date fields. Please add at least one Date field with required start and end dates if you wish to use Resource Conflict with the Date module." This goes away when one reverts to selecting the original "Required," but then you've got to contend with two date fields again.)

Thanks.

Here's an updated version of my patch for the 6.x-2.6 release of the date module.

thanks a lot highly appreciated

This is an amazing addition and I think should be committed to the the api.. thanks a lot.

Still for 2.6, but will now success with drush_make, since it's from the module root as opposed to the "modules" directory.

Patch in #33 works great. My only comment would be to change all preg_match()'s to strpos(), since it's not really necessary to check if required or timeonly is in the beginning or end of the todate, and preg_match is slower then strpos.

Changing version to 6.x since that's what the patches are against.

Here's a new patch for 6.x-2.x-dev that replaces all preg_match()'s with strpos()'s.

it would be awesome to see this committed.

Updated patch for the 6.x-2.7 release.

subscribe.

trying the 2.7 patch and I got this:

can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ruN date-6.x-2.7-org/date/date.module date-6.x-2.7-after-endtime-patch/date/date.module
|--- date-6.x-2.7-org/date/date.module 2010-11-29 18:22:00.000000000 +0000
|+++ date-6.x-2.7-after-endtime-patch/date/date.module 2011-01-04 18:01:28.000000000 +0000

Great functionality !

subscribing...

If anyone is interested, I create a module datetweaks that will automatically update the "to/end" field when the "from/start" field change based off the current duration. I think in most cases, this will satisfy the requirement(s) in this issue.

Anyhow - a different solution to the problem.

subscribe

subscribe

subscribe

+1 patched by hand (don't know git) and it works great for me. i'd love to see additional improvements to have a duration option in the field's display settings or something for views, but i can totally work with this. thanks!

don't know if this will help anyone, but what I did to display the duration was to add a computed field and add this as the code to compute the displayed duration. this patch is great for entering the to and from and only having to enter a time to specify duration, but doesn't really address how to display that duration (that I can see). anyway, a computed field with the following snippet will get you there (change field_your_datetime of course).

	$from = strtotime($node->field_your_datetime['0']['value2']);
	$to = strtotime($node->field_your_datetime['0']['value']);
// this is GMT with no lead zeros, so it looks like 1:30 for something an hour and a half long
	$duration = gmdate('g:i',($from-$to));
//this is specific to computed_field module
  $node_field[0]['value'] = $duration

Updated patch for 6.x-2.8. Note that before applying this version of the patch, you must apply the patch in #1039192: date fields filled by date_popup get wiped on full/part form regeneration.

Unfortunately the D6 version of this module is no longer supported, but we appreciate the time you put into this. If this problem is relevant for D7 too, please reopen the issue. Thanks.