Create a Time CCK type that only stores seconds & timezone. It's a relatively advanced coding project, with a chance to look at the CCK(Content Construction Kit), Drupal data storage and api issues. There is a strong need for this project in the community, and a chance to show off some module building and ninja PHP coding skills.

I originally though it might be too hard, but seeing some of the completed tasks and the fact that the scope is fairly limited, I've reconsidered.

Description

Drupal has a date CCK type which is used quite extensively. Although it allows users to provide granularity which includes hours, minutes, seconds and timezone, it does NOT allow storage of a time format that is not linked with an actual date (year, month, day), because the granularity can only be set from the top down.

A Time type would allow greater flexibility for a number of tasks. Consider:

  • Scheduling: Consider a class schedule. The time may always be the same for multiple days; if it changed, then it would only have to be updated in one place.
  • Proper display of calendar items: When site visitors enter events for a play on multiple nights, they generally pick a 'from' date of Thursday 7pm and a 'to' date of Sunday at 9pm, which of course spreads a single event across multiple days, instead of their intention of saying 7-9 on these days.
  • Time entry (as duration): Enter how many hours/minutes spent on an item, but not an exact accounting of when it actually happened

Project parameters:

  • The settings page should have widget choices for textbox input or dropdowns (like the Date module)
  • The settings page should differentiate between time as clock value or duration value (to know how to check validity, since 25 hours might be a valid duration entry)
  • The data storage should be two fields: 1) seconds from midnight, which would allow easy calculations when adding to a separately stored datestamp, and 2) timezone (for clock entries)
  • Display formatting should offer 12/24 hour clocks, and H:M:S granularity for duration entry
  • Bonus: include a javascript dropdown, like this:
    http://www.texotela.co.uk/code/jquery/timepicker/

Ideally, this project will eventually merge with the date module.

Resources

rleigh (Roger) will be the owner of this task (unless KarenS, date programmer, wants to get involved)

Comments

cwgordon7’s picture

cwgordon7 commented

Wow! This is a great idea! My only concern is that you are asking for too many features: just asking for 2-4 major ones would be hard enough. (Perhaps basic time entries, duration entries, and 12 hour/ 24 hour settings). But otherwise, nice idea, well thought-out, interesting task!

-cwgordon7

cwgordon7’s picture

cwgordon7 commented
Status: Active » Needs review
rjleigh’s picture

rjleigh commented

Agreed, it may be too much for this, so we can pare it down to the essentials.

aclight’s picture

aclight commented
Status: Needs review » Needs work

Why start this out as a separate module now if your intent is to merge it with the date module? Is that because you think it will be easier for the student to do it this way right now? Just curious.

wmostrey’s picture

wmostrey commented

This absolutely belongs in the date module, and making it as a separate module first is only going to cause confusion and a lot more work. As the maintainer of the date module to mentor this and you'll be fine.

rjleigh’s picture

rjleigh commented

Why a separate module? Very valid questions, but here are my reasons:

  1. The CCK is difficult enough without requiring knowledge of the date module. Besides, the APIs and data storage there are focused on a complete date scenario as described above. I think accommodations there should certainly be controlled/created by that maintainer.
  2. I think most date & CCK development is focused on major changes, some to do with 6.x, but some to do with massive changes proposed for CCK itself, especially regarding integration of the FAPI. There seems to be little likelihood of new features till these changes take place, and it seems unlikely that this type of feature will be part of any 5.x date release.
  3. I would like to see this in a timely manner, and items 1+2 = probably a six month wait.
  4. I disagree that the future path is muddied by this - since storage would be such a simple thing, and the datestamp already uses seconds, writing a data port as part of a merge should be the simple part of the deal. The hard part of ANY future CCK development will be rewriting the input widgets (hard in the sense of a major change - IMO I'm glad to see the move to FAPI).
  5. Drupal module development has countless examples of new features appearing as separate mods, only to merge later (in fact, that's how most new features become core, right?).

I do agree that the date maintainer should know about this, and I'll write her now.

karens’s picture

karens commented

Lots of issues here to consider:

1) There is a completely new version of the Date API in HEAD which will very soon be released as the 5.2 version of the module. Any new module which handles time would benefit by using that new API. Any module which might at any point be included in the Date module *must* use that new API.

2) That new version already has created FAPI widgets that can be used to create date/time fields, including jQuery date and time pickers. So there is no need to write new code to do this. The widgets are designed to be flexible -- they can be used to create both date-only and time-only form elements.

3) The 5.2 version has switched pretty much completely over to using FAPI for the widget creation and processing, so anything that might at any time be added to the Date module needs to work the way the existing widgets do.

4) You have marked this as having a 'limited scope' but included things like a timezone field. Not sure why you want to store a timezone when you can't do timezone adjustments on a time-only element, Anyway, if any timezone adjustments are contemplated, that is far from trivial, as anyone who has ever tried to do anything with timezones will tell you.

5) There are comments above about improving the calendar display, but time-only fields won't work on the Calendar without a complete, non-trivial, re-work of that module, too, if it can be done at all, which I'm not sure of. If you want to put things on a calendar, they must be dates (or at least have imputed dates).

6) If the goal is to have way to create repeating dates, that's already being worked in to the 5.2 version. There's no benefit to using a time-only field for that (and I don't think it would solve that problem anyway). Repeating dates will also display on a calendar.

I'm concerned that the project outlined here is too large in scope and overlaps too much with things that are already developed or in development. There is a place for a time-only field, but I think this proposal goes past that.

What might work would be to take a good look at the new Date module to see what is already available, then identify specific use cases and examples of situations where none of that will solve the problem, then create a different proposal that is more limited and targeted to situations that clearly need a different type of field with clear examples of how they would be used.

And maybe the GHOP project could be that analysis, rather than the code.

rjleigh’s picture

rjleigh commented

Hey Karen,

Glad you had time to take a look. It certainly sounds like you have accomplished many of these tasks, and that the 5.2 version is farther along than I thought (would you say it's quality is alpha? beta? RC?). I had tried to look for more details about that status when I started this proposal, but didn't see them. Looking at the Date module page now, I felt like an idiot at first, until I realized that you just added that info.

So, to respond to your post here:

  1. agreed
  2. great; I was under the impression that wouldn't be possible till the CCK changed, so I'm quite happy about that.
  3. agreed
  4. I have not done that, so thought it was merely a matter of storing the offset and adjusting -+. But I actually agree that thinking further about it, I'm not sure it would make sense when divorced from a date.
  5. Repeating dates may solve much of the problem (depending on how you implemented that). Does it generate a single node store with multi-date storage as an array? generate multiple nodes? something else?

    Consider the class schedule scenario. My concept was that a node could have a multi-date field (YMD) stored as a datestamp, and two time fields, start and end. To change the time of the class for the array of dates, you'd just change it once.

  6. And to display values in a calendar, the time (stored as seconds from midnight) would just have to be added to the date (we could write our own mechanism, or use something like computed field). How hard is it to get the calendar to recognize something like this as a date value?

To give some other scenarios:

I need the class schedule example above for one site, but another similar schedule issue would be a radio station (my actual need). Here, separating the time slots from the dates would also be useful, and I'm working now on some code to handle scheduling as "first saturday" or "every tuesday", which would then pair with the time for a regular slot.

Another site needs a time entry module, and I don't want to have to make people enter specific slots, just "1:40" as time spent.

So, maybe the Project Parameters above should be pared down to this:

  • The settings page should have widget choices for textbox input or dropdowns (like the Date module).
  • The settings page should differentiate between time as clock value or duration value (for validation, since 25 hours might be a valid duration entry).
  • The data storage should be in seconds (would essentially be from midnight as a clock value, or just duration.)
  • Display formatting should offer 12/24 hour clocks, and H:M:S granularity for duration entry.
karens’s picture

karens commented

I've been posting around in various places about the 5.2 version I've been working on, including on quite a few Date and Calendar issues and in the Events group on gdo, but if you weren't reading those issues you might not have seen it :)

The new Date Repeat is going to do what you want for your schedule -- it will have one from/to date and time field plus a bunch of selectors so you can say something like 'every Tuesday' or 'the last Friday of every month'. It will then compute the dates that match your criteria and add a multiple value field for each one to the node, similar to now when you create individual multiple dates, except automatically created. All of that is designed to work with the Calendar, since it is just another way of presenting the multiple value date fields that already work in the calendar.

Anyway, if we pare this down to creating nothing but an individual time field and widget, it becomes a manageable, and possibly useful, project. It could either be incorporated into the current date module or added as another optional module in the Date/Time group, like Date Copy is. If it is going to be a simple element (no 'from/to' options), it doesn't need much of the complication of the current module, so that might be a justification for keeping it separate, and it would be much easier to code a separate module than to try to patch a moving target like the current code. It wouldn't necessarily need its own project, if it's useful, I could incorporate it into the current Date package, which already has several modules, or just blend it into the current code.

Expanding on how that time widget could be combined with other elements or added into a calendar could be future projects or tasks, for now I'd keep it to a stand-alone element that will not work in a Calendar, it will still display in nodes and can be used in Views. And I would add a requirement that it be patterned on the way the other 5.2 date fields and widgets are coded (using FAPI and taking advantage of the Date API's new reusable form elements).

karens’s picture

karens commented

Oh, and I would call the current code somewhere between 'beta' and 'RC'. I'm hoping to make a development release soon.

[Edit] Except for the Date Repeat module, which is still alpha.

rjleigh’s picture

rjleigh commented
Status: Needs work » Needs review

ok, so considering Karen's input, here's a streamlined request:

Create an individual time field and widget

Project parameters:

  • The settings page should have widget choices for textbox input or dropdowns (like the Date module)
  • The settings page should differentiate between time as clock value or duration value (to know how to check validity, since 25 hours might be a valid duration entry)
  • The data storage should be in seconds (from midnight as a clock value or just a total for duration)
  • Display formatting should offer 12/24 hour clocks, and H:M:S granularity for duration entry
    Ideally, this project will eventually merge with the date module.
bomarmonk’s picture

bomarmonk commented

I'll second this, as the Time CCK project isn't working well for Drupal 6. So it would be great if there was an individual time field widget/field for date.

wmostrey’s picture

wmostrey commented
Status: Needs review » Closed (fixed)