Time without a date feature

Yes there is an ISO time standard and we're already using it, and yes an iso format with no date would be the way to store a time-only record. I have to think about this though since many functions in this module make the assumption that you're creating something that really is a date and you're proposing something that is not, so I'm not sure how many things would need adjustment for this to work.

I'm posting within this issue because it seems related.

I have been trying to get familiar with CCK and the Computed field, and in one of Agileware's examples he uses your module in the following context:

This example uses KarenS' date module to create two date fields field_start_time and field_end_time which record hours and minutes. We then create a new computed field to work out the duration as a decimal number of hours (so 1.5 is 1hour, 30minutes).

The problem that I am having is that your module doesn't seem to allow a field that records only hours and minutes. Am I misunderstanding something here?

I'm trying to put together a timesheet application at my company where users would update their schedule and the totals could be computed.

Any help would be apprecieted.

You are correct that currently the 'year' field is required. This is partly to make validation more manageable, and partly because I have trouble understanding why a 'time' would not also have a 'date', which is why I haven't been in any particular hurry to do anything about this.

In your example, a timesheet, the 'times' do have dates, you just may prefer to display only the 'time' portion of the date, which you can do now. You have an almost unlimited amount of control over the display (open up your 'advanced display options'), so you can set your field up to display only the time, and you don't need to create a date that has no time.

Anyway, if there is a reason to create times without dates, one of the biggest challenges would be to think through a system that can be used to validate results. Currently I make a date out of what is returned and then check if it is a valid date using php date functions. If that can't be used, validation gets much more difficult. If you have a good use case for creating times without dates and you want to try to make a patch to adapt the module not to require a date, I'd be glad to review it, but creating something like this is not very close to the top of my TODO list, and you'd still need to convince me that it is really needed :-)

Thanks for your reply, but I was able to adapt the regular text integer field to do what I needed. I guess what threw me was that example didn't explain very well how to setup the date field.

It makes sense that times should be attached to a year, but in my timesheet example, I intended the 'end of schedule period' date to be chosen at the top of the form and the times to be entered would be assumed to correspond to days of the week (sat-fri) within that period. Clearly, my app is not that sophisticated.

Thanks for the module.

I was looking for a way to record a time (duration) without a date. Ideally would want to highlight Hour/Min/Sec in the 'granularity' box and record just that.

Why? Because on a sporting site, we have a number of 'challenges', and users can report how they've performed on each. How they went is entered as a node - which has a noderef to the original 'challenge', their comments, etc, and of course the time taken to complete.

I know one could use a text field and some sort of PHP validation that is in the form "HH:MM:SS", but it would be nicer to have a proper field here.

Another alternative would be to have an integer field with number of seconds, but again, that is horrible for the user.

If this could be stored in the database as an integer (or decimal for those people who might need this - we don't, but someone might) number of seconds but formatted "HH:MM:SS", or "MMM:SS", or "SSSSS.ss", or whatever I guess that would cover most scenarios.

If any other options sound easier, or there's another way, would love to hear.

Thanks :)

Raintonr,
if you (or others) are interested in a module for recording 'durations', you can send me a message. I needed the same thing, and build a cck duration field type recently. You can select years/months/days/hours/minutes/seconds from a granularity box, and the data is stored in ISO format for duration. For example P1Y2M3DT4H5M6.78S would be 1 year, 2 months, 3 days, 4 hours, 5 minutes and 6.78 seconds. But any of these could be left blank, so years is for example not required as in date module. Note that the number of seconds can be a decimal, the other elements are integers. A duration field is optionally stored as seconds as well, which can be used for computations. For displaying: either the above ISO format, the number of seconds, or HH:MM:SS for time durations can be used.

+1 for time without date feature

"... you'd still need to convince me that it is really needed :-)"

I understand this is not a priority for you, but there are several areas where I would find this extremely useful. I'd like the option to create schedule-like dates; i.e. a date item that refers to 1-3pm each day in a range (as opposed to a start date with 1pm through the end date of 3pm) - I know that that can be accomplished with multiple entries, but that would be a chore in my case.

It could then be further abstracted for scheduling, say wednesdays from 1-3, or second thursdays from 1-3. I can build this separately, but it seems like it should be here.

I'm looking for this in the 5.x version, BTW.

thinking a little further on these lines:

Now, I understand the desire to use standard strings for php validation, so couldn't a time entry be an ISO date that has just a year and time? (I'm not sure where that config would be valuable otherwise, so it might not even need further type-marking).

The year could essentially be discarded for display, or calculation with Y-M-D only dates. So, I can create two time fields, for instance, showing a 1-2pm slot, and they can be combined with an array of single Y-M-D entries to create a schedule (for a lot of entries, that would be more efficient). It would easily allow skipping days, but not require completely separate node entries for multiple occurrences.

If an end time is later than a start time, a +1 day could be inferred (to cover time ranges past midnight).

I can't imagine that more people wouldn't find this to be a highly valuable addition to an already important mod.

+1 for time without a date feature.

The reason I would like this feature is, I am creating a list of meeting groups that will meet regularly for several months. The start and end dates are not known, but the meeting time IS known. So I only need to record the meeting times, and it should be a time of day, not just a duration.

Other examples of use cases would be anything that involves a time, but no specific date.
- What time do you usually get up?
- What time are most of your rehearsals?

I'm postponing this until the 5.2 version is working. I think that the way I'm using FAPI and the PHP 5 date functions in that version will simplify the code enough to be able to try to add a feature like this in (probably as an additional, optional module instead of as an add-on to the Date module).

Thanks Karen;

when you do get the time to look at the code, I'd be glad to test things.

-Roger

New features won't be going into 4.7 any more.

Moving this to HEAD. No new features will be added to the 5.1 version, but it could be considered for the 5.2 version now in HEAD.

+1 for time duration.

This duration data type is useful for describing multimedia and events.

Media like video clips, TV shows, films, music, advertisements often see duration as important. Am I looking for a 15 second drum loop, or a Wagerian opera? Can I play a 30 second commercial, or the full minute?

The duration of an event matters, even before it is scheduled for a specific day. Is a training course two hours long or fifteen minutes? Which appointment do I schedule in the remaining time before lunch on Thursday?

Durations are an important parameter of these items and others.

Subscribing, as I'm currently working on a generic "duration" element/field. I don't have high ambitions though to make it integrate with the Date module, it's just going to be a simple widget for displaying a time value (e.g. "3.5") and metric ("days"). Let's see how far I get. No idea if that's what's planned here, or if it should possibly be operating under the Date module family umbrella.

Ok, I added an initial version of my module to drupal.org, named Duration. Still without CCK features, which means that only developers can make use of the form element at the moment, and nice formatters are not implemented yet. The editing widget might also not fit your needs yet - it's currently a value/metric duo as described in the previous comment, or alternatively a single dropdown with fixed duration options to choose from.

Extending the element to suit your needs should be pretty easy though (for developers), as most of the groundwork is there. In comparison to the former version of this form element (which was only used privately in my Temporary Invitation module), I seem to have got the data structure right this time - reading the comments and use cases here played a good part in this, too :)

The issue for storing generic duration data is that you can't really express it as time deltas (that is, seconds) because once you reach larger units like months and years, those do not necessarily have similar length (31/30/28 days for a month, 365/366 days for a year). If I want to schedule stuff so that it happens exactly in a month, on the same day as today, the time delta approach falls down.

What I'm doing now is to take the mktime() parameters - seconds, minutes, hours, days, months and years - and store them separately, with a set of helper functions to ease the display and management of that data. Plus milliseconds, because exact demands like for video and audio media could make that necessary.

So, like it or not, depends. Anyone who wants to help out is invited to contribute!

+ 1 for this feature

Looking to add time to-from to an existing module that only supports Date of occurrence (station playlist)

The module as built is more interested in the current schedule of a station, and then the date of the actual playlist. (less archival than my goals)

Having time only would allow me to interact with my needs for the module without having to interfer with the designers vision.

While still limiting the wear-tear on the Djs, avoiding multiple data entry repetition, and of course limiting chances for user input error.

Well, I guess there is this then: http://drupal.org/project/cck_time

(subscribe)

I want the ability do month/day but not year, because I have a site that has the birthdays of the teens show up in a block. I do not want their ages also showing up. Right now I use a custom php date format. What would do this for me is to allow me to only prompt the user for a month and day and then use my existing php date format. The date module would just add the current year and then ignore it.

Ok, so the Duration module (actually it's three of them now: API, form elements, CCK field) has been completely reworked and now features a working CCK field, but also a reusable PHP object that can be used for parsing ISO 8601 duration strings. If you want to have a duration field (as opposed to "time on any date" as with the cck_time field above), you might actually like it. If you don't like it, it's probably easy to add the features that you need to like it.

Check out the new release 6.x-0.9 and enjoy! Given that there's now a module for each of the use cases, should we close this issue?

Thank You * 1000 !

I am bit confused!

I was able to do time without date with version 5.x-1.8. I updated to 5.x-2.0-rc, now it broke my app. I get an error message "A valid date cannot be created from".

I wonder if the way I made it work was just an accident! This was how I did it with 5.x-1.8: I just put "h:i A" in "custom input/display format", then checked granularity with "hour, minutes" only.

Can any expert throw in some comments?

thx!

pulling this from postponed - see #10

I'd like to support this feature request as well. I'm putting together a local music scene site and every gig we list has a separate "doors open" and "show starts" time. Currently one must enter the date of the show for each time and it leads to incorrect gig listings due to user input error. The ideal would be to have a single "show date" field then two time-only "show starts" and "doors open" fields.