Rework core CCK widgets to FAPI elements that have Field counterparts

+1 ditto

Desired results is an element such as this:

[2010-12-12] [12:00PM] [2010-12-12] [14:00PM] [Timezone]
From                   To                      Timezone

Also, when doing AHAH callbacks, what magic is required to get the JCalendar popup working on the returned values?

Many thanks

If date is the core date handling API for Drupal, this is really a must IMHO. [if not already done]

It would be great to have the core API as a small module that handles dates cleanly and is extendable. Using Postgres, other date apis that I've used are in the fairly tiny (30K or less), but making this work on any db definitely makes this harder. It would be good to have the other stuff in other modules that really have nothing to do with the DateAPI. Then you could push to get this into core and maybe by 2012 Drupal will be able to handle all common "base" fields internally. I can not see this hapening if all the other stuff is bloating the module like the date nav system etc, which appears to be talored to specific third party modules anyway. Anyway, sorry for my Friday morning rant. Great work as a whole. :)

"Also, when doing AHAH callbacks, what magic is required to get the JCalendar popup working on the returned values?"

This may not be the best, but it seems to work. It grabs the JScript info and removes the included JScript files, before adding the settings. There is an easier way that I've seen in the past, but I can not find the code at the moment.

<?php
  $js = drupal_add_js();
  $js['core'] = array();
  $js['module'] = array();
  $js['theme'] = array();
  $output = theme('status_messages') . drupal_get_js('header', $js) . drupal_render($target_form);
?>

Getting this all working is a major undertaking. Reworking it is another major undertaking. I already have tried very hard to keep the code modular -- there are numerous separate modules and the core API is the stuff that they all use.

The stuff in the '.inc' files are the parts that could be reworked into separate modules, if someone feels like doing that. But there are lots of interdependencies and many/most of them will end up being required for you to do much of anything.

Pulling Views code out into a separate module would make sense. And maybe the ical code and sql code could become separate modules. Not sure what else could be pulled out.

Also, all the elements already *are* FAPI elements. I never expected anyone to use date_combo, so that is undocumented. All the basic elements are documented in the handbook page about the date API. That part works the same in D6 and D7.

I'm not sure how universally usable date_combo is, it's very specifically designed for the Date field to use, wasn't designed to be totally generic.

I have used a custom one based on this element (hacked clone of...), multiple dates + unique timezone per date delta value. Just can not remember which project :( There are so many configuration options coupled tightly with the module, that I would imagine that this would be a difficult task.

I think the core developers are pushing hard for things to end up as fields. I was told that chx requested that the node example module should move away from the node api hooks, and use dynamically created types and fields. (Side note: Personally I do not think that core is fully designed for this yet, e.g. lacking locks on the types & fields, etc.) So the future usefulness of this could end up being limited, excluding the modularization of the element code.

What is actually actionable here? I have already made every attempt to keep the core API as small as possible. I have already created widgets as FAPI elements. I can't tell that there is anything else I can do with this.

If there is a real task here, please make it more clear.