JavaScript enhanced date fields

Zip is not allowed and I don't know how to add new files when making a patch. Email to the rescue. If anyone else except Chris want to test this, contact me :)

...

BIG mistake. I just realized I coded this whole thing with a recent version of jquery in my misc folder (I needed it for another project). If you do want to test this, use the jQuery update module: http://drupal.org/project/jquery_update

Aaah, you found out...

So you think we should push this for Drupal 5 even if it requires the update module?

New picker (http://marcgrabanski.com/code/jquery-calendar/), fixes most of the issues I had with previous one (except the IE position bug which is related to Drupal/Garland somehow, not researched yet). Even keyboard support.

And the files.

Added and renamed labels. No description support yet (don't know if we really need it, complicates things it seems).

Updated CSS file. Place in "pickers" folder.

Darn it. The jQuery calendar is not under GPL (CC strangely enough). Note to self: always check header. I'll see if can get him to dual-license it, but if not we probably have to go back to datePicker.

On track again, the calendar is now GLP, thanks Marc Grabanski! It uses V3 but that should be ok(?):

Copyright (c) 2007 Marc Grabanski (http://marcgrabanski.com/code/jquery-calendar)
Dual licensed under the GPL (http://www.gnu.org/licenses/gpl-3.0.txt) and 
CC (http://creativecommons.org/licenses/by/3.0/) licenses. "Share or Remix it but please Attribute the authors."

* Added firstday support
* Reverted back to use no animation for the calendar as it caused a strange bug when used (I used speed: 1 to work around an Opera bug). When startdate and endate fields was manually cleared it was never updated to the hidden date fields. I don't want the animation anyways so lets hope the Opera bug is fixed soon.
* Re-introduced radios to get a cleaner interface. I tried with a complete JavaScript implementation but settled on doing it serverside which works much better with less code. Active status is now set to "2" if duration is specified, do we want to "normalize" it to "1" when saving/updating the node?

Todo:
* Check for jQuery Update module
* Your timezone code returns 7200, how is the best way to convert it to +0200?
* Labels/descriptions could probably be improved.

Known issues
* Position in IE is still off (I think we should release this anyway)
* The Opera bug mentioned above

The problem is that I need it in the format +0200. I'm not sure but looking at http://api.drupal.org/api/function/format_date is seems a bit complicated. Could we do it my way? I can add some more comments to it...

Added check for jQuery update and fixed a typo in firstDay.

This effort will most likely be synced with the date_popup module: http://drupal.org/node/157127. (Note to self: always search search search).

Can't promise anything, but yes we should and I think it's perfectly doable, be it date module, an own solution or jstools (given in prefered order).

I think it's a difference here from VotingAPI. Date API and date_popup would not be required so they won't stop us from touching are own code. As with jstools we would do a module_exist().

The way date_popup splits date and time with PHP instead of JS is much more robust. We could of course do that as well but it seems like a lot of duplicate effort re-writing this. When I put a lot of time into this previously I really felt that this was something that would be best abstracted away form advpoll so it could be of benefit for other module developers and users.

I tried date_popup earlier today. It had some issues (calendar display and saving dates - try the author date field or change "textfield" to "date_popup" for end_date or start_date). But if we can get Karen to work with us making it stable in the near future I believe that is our best option.

date_popup (HEAD in date module) was just updated and it seems to work pretty well. There are some styling issues and I still prefer my time picker (http://labs.perifer.se/timedatepicker/), but this is a good start and I still think it's our best option.

This patch just enables the pickers to start playing with it. We need do some styling but that could even go in in a seperate patch. I also just submitted this issue to the date project which should make it possible to rename the labels easily: http://drupal.org/node/201432

Seems like we have to dig a bit deeper in date_popup. Looking at how the author date is implemented this patch might be the better approach, need to look at it some more.

About the date format, using the patch in #28 the default short date format (admin/settings/date-time) is respected, which I saw as one of the big benefits of using date_popup. On the other hand, this patch defaults to YYYY-mm-dd. But I would think that's a bug.

Not sure what you mean about "easier for sorting, automated searches, etc.".

In my tests date.css is not initiated. You must have some other date related content on the page (e.g a calendar in a block?). So I don't have them inline, but the screenshot looks good :).

We need http://drupal.org/node/201432 to get in if we want to fix the labels without using form_alter (seems a bit silly to form_alter your own elements...)