Better interface for date fields

I wrote something similar to http://simon.incutio.com/archive/2003/10/06/betterDateInput for Drupal using the HTTPPost function in drupal.js. Contact me if you are interested. The widget does not yet take care of timezones though.

I've been playing with this a bit and have been thinking about how best to configure a date field to address some issues that will come up when designing an interface (for whoever ends up doing it). Here are some of my thoughts/questions:

1) I think you will need a way when creating the field to specify optional limits for the field. We obviously will test for a valid date, but I can see where someone might need to make sure entered dates are within a certain date range or no later than x or no earlier than y.

2) The timezone issue is going to be messy. I have done a fair bit of research on this and looked at the way that timezones are currently handled in Drupal core (on the configuration page) and in the event module. The current process is to store a gmt offset which is insufficent information to know what to do with dst. One interesting part of a solution is referred to at http://drupal.org/node/20927. In a custom CMS I wrote, I ended up using the PEAR date and timezone functions along with a module I wrote to adjust timezones using the olson database. For that to work, the timezone cannot be stored as an offset, it must be stored by name, since the offset will vary depending on whether or not dst is in effect. As an interim, I suppose it would make sense to use the method that is in core now and work together to improve on it.

3) Related to the issue above, which timezone do you want? The site timezone, the user timezone, or a timezone selected at the time the field is created? Again, the best solution might be to offer an option to the person creating the field (similar to the way the event module handles it).

4) How should the date be displayed? One option would be to give the user who is creating the field a drop-down list of formats (like that on the system configuration screen) and have them select the one they want. Another alternative is to have them choose between the system-configured formats (long, medium, short) and then display it in the user's chosen format using the format stored in the variables table. The last probably makes the most sense, or maybe it should be a user choice -- just trying to think through all the options.

5) Do you always want drop-down boxes? Probably not for the year unless you have limited the options to just a couple of years. Autocomplete boxes could be an interesting alternative that might be easier on the end user (I don't know how to create them myself).

6) The user creating the field will probably need to have an option to control whether or not a time can be chosen or just a date. Or do we leave time out of this even though the date field format has a place for time info? The inclusion of time info adds several other options (time required or optional? offer hours minutes and seconds, hours and minutes, or only hours?)

Maybe this has been discussed already somewhere that I missed, but it looks to me like these issues need to be clarified, so I thought I'd open up some discussion.

event module has a reasonable UI for this already ... actually the current text field is OK but it requires this format: "%name must be entered in ISO 8601 format". would be nice if it accepted everything that strtotime() does.

I'd like to hear some responses to http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/timcn/calendar/

Simply copy the module and the js to modules/calendar, enable it and go to create content->date. You can enter almost any given date and the module converts it to a unified format. This is a proof of concept as there are quite some things to improve such as adding compatibility with timezones and possible performance enhancements (hook_init).

Probably you could even use something like an auto complete for ambigous dates like "03/04/05". Another enhancement would be to allow the user to enter just certain parts of a date, for example omitting the exact time.

I think this has possibilities. It could be one widget option in the date field (along with a more traditional select box, a plain text box, and maybe a javascript pop-up calendar).

What happens if javascript is disabled? We need it to degrade gracefully.

I made my own version of à "js calendar" date widget.
It uses dynarch's dhtml Javascript Calendar (GPL), and it works pretty cool.

I don't have any cvs account, but I can post my module here if you are interested.

I'm a long way along on getting something put together for this. I have a nice widget drop-down select list that collapses nicely into a single row (instead of multiple rows like many other drupal date fields). I have selectors you can use to decide what format you want date displayed in on the view (using a concept similar to what is used in the system settings where you see a drop-down list of a date formatted in various ways and you can select which one you want.) I've set up a way to have very fine-grained control over the selectors (like what value to increment the minutes). As I was putting it together I realized it would be very easy to set it up in a way that things like the date selector can be available as a part of a date API for other modules, so I'm adding in that capability, too.

Based on a comment in this thread, I also changed the text field widget so you can type in anything that strtodate can translate and it uses that function to convert it to an ISO date (instead of asking the user to type in the ISO format). I'm also adding in validation, and am working on timezone integration.

Just a bit more to do and I'll post the results.

Just one question. The stated format for the date is ISO 8601 as YYYYMMDDTHH:MM:SS, however all my googling around says that there are two acceptible formats for ISO 8601 -- ISO Basic (YYYYMMDDTHHMMSS) (no separators) and ISO Extended (YYYY-MM-DDTHH:MM:SS) The format in the date module documenation is neither of these. Is there any reason not to go with the standard for ISO Extended? If so, we need to add 2 characters to the size of the database field. Also, the standards say that if the date is GMT it should be followed by a Z, otherwise the assumption is that it is in a local timezone. Since we are storing the date in its GMT value, we could add one more character and store the Z at the end of the string to be in perfect conformance with the standard, thus ending up with YYYY-MM-DDTHH:MM:SSZ.

Is there any reason not to do it that way?

KarenS : that seems pretty exciting.
Please dont forget locale-specific time formats :-)

strtotime seems US-format only - and in France Xmas is "25/12/2006"...

OK here it is, rewritten to go with the latest database changes...

I am quite sure there are bugs and problems to work out, but I think it is coming along. The module provides a plain text field which tries to create a valid iso date for anything that strtotime can handle (and yes I know that won't work for shortcut dates in non-American formats and for pre-1970 dates, but you can use the select list for those things.) It also has a drop-down select list that collapses nicely into a single line, with options as to exactly which elements you want to collect in the input form and how you want to display them in the output. The select list should be able to handle dates from 1850 to 2050 (not all of them have been tested :-)). The module has 3 ways of handling timezones -- the site's timezone, gmt, and a date-specific timezone (entered when you edit the date). The option to use the user's timezone won't work since there is no way in the current Drupal system to find out what the user's timezone is. (We know their gmt offset, if they bothered to set it up, but not their timezone).

The module uses pear date for many calculations because pear date allows the use of dates prior to 1970 and also provides an extensive library of date calculation functions. I know the use of this library may be controversial, but I think there are many advantages and I have tried to minimize the disadvantages. For instance, I created an option where you can show text like (XX days from now) or (XX years ago) next to the date. A future use could be to create a date calc widget that creates a date by reference to another date field. For instance, you could have a date called 'Last review' which is input normally, then create a date called 'Next review' which is referenced to last review and incremented by 1 year, or 90 days, or whatever.

One place pear date can create problems is in trying to detect whether a timezone uses daylight savings time (which it needs in order to do timezone conversions). The way I have things set up I *think* the worst case situation is that it will fail silently if it cannot get dst figured out, then be 1 hour off. Pear date uses putenv to figure timezone info which can create problems if getenv returns false on a poorly configured system, so putenv is initialized when pear date is initialized. To keep the problems of pear date to a minimum, pear date is included as a sub-directory below the date module, and is initialized and made the primary include path when the module is initialized. That way there should be no problem if there is a conflict with some other version of pear date on the system.

Installation:
1) upload the attached files to the cck directory. It will create a pear directory underneath it for pear date files. There are several files -- the date.install, date.module, and date.inc, date.css, and the pear date directory. Since it is a complete re-write, I included the whole date.module rather than a patch.
2) If you've already created some date fields, remove them and uninstall and reinstall the date module. I needed to modify the database structure.
3) Go ahead and try to add dates to a content type.

Anyway, here it is.

A little typo was left in the pear file Date.php. Here it is fixed.

Arg! I tried to switch from one iso date format to another and now see I didn't get all the changes consistently applied. I will post another attempt tomorrow that hopefully will have everything fixed :-)

OK, I think I have everything fixed now (and did a little other clean up while I was at it). Hopefully this time it really does work.

yched mentioned a dynarch's pop-up js calendar and it is now available as a drupal module (see http://drupal.org/node/57285). I have been playing with it a bit and it looks like it could be nicely integrated into this module as another date widget. It even can be configured to return a date and time in exactly the iso format we want it in -- very slick -- and best of all it degrades nicely to a plain textfield that you can just type a date in if js is not available.

If you try it out, note that the js requires the very latest cvs version of form.inc because earlier versions of form.inc had a bug that kept the js from working.

timcn and yched -- it sounds like you both know javascript, it would be great if you could check out the javascript tool link above and maybe you can help improve and add to the toolkit. I posted a modification question on the js toolkit issues page, and maybe one of you can figure the answer out.

just tried the date_1.zip linked karen and itr returned an error

"year must be a number between 1900 and 2050."

Not sure where to look to solve that, so I thought I'd flag it up here. Will post if I find out what's causing it.

Dub

forgot to mention..using Drupal 4.7 release RC3 + content.module,v 1.48

dub

There were lots of changes made to cck after I finished this module, and I haven't yet determined what corresponding changes are needed in the module. I'll try to figure it out in the next day or so. In the meantime, posting specific errors here will help me get it cleaned up.

Thanks!

As stated earlier, ISO 8601 Extended is YYYY-MM-DDThh:mm:ss. I changed the regex in the the date-widget validate to

if (!preg_match('/[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}/', $item['value'])) {

(hope that works, I'm no regex expert). I did this because the jscalendar chokes on 20060419T14:03:27. The popup returns a NaN.
Now, for the jscalendar I can use

$form['#jscalendar_ifFormat'] = '%Y-%m-%dT%H:%M:%S';

and everything works fine.

I have tried to make all the changes needed to accomodate the new way that cck works. This module also changes the date field size and default to comply with the iso format (YYYY-MM-DDTHH:MM:SS) and adds a timezone field to the date field. It won't work if you don't make the database changes. You *should* be able to go to upgrade.php and see that a database update is needed and make it there.

As before, the upload includes the pear date folder, so drop the whole thing into the cck folder and you will end up with something like:

cck/date.module
cck/date.inc
cck/date.css
cck/pear/Date.php
cck/pear/Date/...

This also includes the widget to use the jscalendar widget as a date selector, if it is installed. I added in help text (admin/help) to explain the options.

I'm very keen on seeing something like this get incorporated, and I finally got a chance to start testing this (code from #19), but am having trouble with the database update. I'm getting lots of errors like ...

# user warning: Duplicate column name 'field_mydatetime_value' query: ALTER TABLE node_content_one_of_each ADD COLUMN field_mydatetime_value varchar(20) NOT NULL default '0001-01-01T00:00:00' in /Users/ray/dev/drupal/sandbox-cvs/includes/database.mysql.inc on line 120.

# user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1,4), '-', SUBSTR(,5,2), '-', SUBSTR(,7) WHERE field_name = 'field_mydatetime'' at line 1 query: UPDATE node_data_field_mydatetime SET field_mydatetime_value = CONCAT(SUBSTR(,1,4), '-', SUBSTR(,5,2), '-', SUBSTR(,7) WHERE field_name = 'field_mydatetime' in /Users/ray/dev/drupal/sandbox-cvs/includes/database.mysql.inc on line 120.

Is this a bug in content_alter_db_field() or date_update_4() or something else?

I guess my next step is to try it on a test site that doesn't have existing date fields.

There have been lots of database changes and those of us who have been using cck for a while may have some inconsistencies in our databases so it's hard to figure out what are problems with the update and what are errors in the code. The easiest thing is to just manually fix the database and change the entry in the system table to indicate that the update has already been applied.

The database change is to make the field bigger, to hold a full iso date, change the default format for that field to match the iso format (YYYY-MM-DDTHH:MM:SS) and add another field to hold a timestamp.

There have been numerous other changes to cck since I posted this, so I am not sure if it still works correctly or not. I will need to test it again. Or go ahead and use it, but try it somewhere where it won't hurt anything important if it's broken.

Did some quick testing on a fresh database. Didn't run into anything that doesn't work so far, but I haven't tested exhaustively. I think this is looking very good. Nice work, Karen.

JonBob, just curious ... at this point are you thinking that Karen's code is likely to be used as the basis for fleshing out the date field? If so, I'd love to see it get committed sooner rather than later so it starts getting wider testing.

I'm planning to using CCK with some date fields on a site I'm beginning to build and would love to know if it's likely to take a different direction.

Found this after about 4 hours of working on my own. Guess I should have looked a little harder.

Very nice work Karen.

Found a couple of things when using 12hr time format:

1.) hour selector still shows 00 - 23
2.) pm values are not converted to 24 hour format before saving to database

So I dug into the code and changed this in date.inc:

~ line 71 - changed the variable $ampm to $show_ampm as $show_ampm is what was defined above.
~ line 73 - changed $i to start at 1 instead of 0, as we do not use 0 in 12hr time
~ line 73 - removed the zerofill for 12hr format as this is not usually how 12hr times are displayed.
~ line 231 thru 243 - not sure if this was the right place to put this, but I added a conversion from 12hr format to 24hr format before we convert the array to iso time inside the date_selector_make_date() function. code is below:

  // convert 12 hour time to 24 hour time
  if (isset($array['ampm'])) {
    if ($array['ampm'] == 'am') {
      if ($array['hour'] == 12) {
        $array['hour'] = 0;
      }
    }
    else if ($array['ampm'] == 'pm') {
      if ($array['hour'] < 12) {
        $array['hour'] += 12;
      }
    } 
  }

@massekotti: I mostly agree with your changes. However, I think the conversion from 12 hour to 24 hour should go inside the date_array2iso() function. I've attached a patch for Karen's date.inc that includes these changes.

@KarenS: I'm guessing this is just a missing feature, but I wanted to double-check that I'm not just missing something somewhere ... I'm using Views to generate a listing of CCK nodes that includes a date field. I was hoping that the date would be displayed using the format selected in the configuration of the content-type, but it just outputs the raw ISO format.

The views integration was set up for the previous method of handling views, so it doesn't work right any more and needs to be tweaked. The themeing is also outdated by the latest cck changes.

I would be more than happy to get everything fixed, but am waiting to see what JonBob's thoughts are before spending a lot more time on it in case he's got something completely different in mind for the date module.

Fair enough.

So ... JonBob ... any thoughts you care to share? :-)

Why was the decision maybe to store the Date in a varchar in the DB? Wouldn't it be easier if the date was stored as a Date in the Database.

I know that both mysql and pgsql have good support for Date including the timezone.
http://dev.mysql.com/doc/refman/5.1/en/date-and-time-types.html
http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html
http://www.postgresql.org/docs/8.1/interactive/datatype-datetime.html
http://www.postgresql.org/docs/8.1/interactive/functions-datetime.html

I would think that using those above would save you work.

Since I am new to drupal and CCK there my be a very good reason for it that I am just unaware of.

Stephen

I've installed KarenS' date.zip update and ran update.php without a problem. All the new options appears and it seems good but...

When I create a new content type using the "select list field", i've got this error :

warning: preg_match() expects parameter 2 to be string, array given in /var/www/drupalcl/modules/cck/pear/Date.php on line 181

Is JonBob AWOL / can somebody else take this on? The hopeless current date interface has been blocking a rollout of an events calendar on SpreadKDE for well over a month now :(

Using 4.7.1 of Drupal and cvs of cck, date.module,v 1.14

I have installed the code supplied by KarenS, added the am/pm patch by RayZ and so far it's working. I'm not using views BTW.

The install update procedure failed but did not do any damage, probably because there was no data in the tables. I applied the
'0001-01-01T00:00:00' change manually and increased the size of the varchar to 19.

There are of course many different ways of implementing date and time utilities, but I'm not sure that storing a date
in the '0001-01-01T00:00:00' format is the right way forward, I am wary of using mysql functions in this context,
these vary quite a bit from version to version of mysql.

I would personally prefer to see the data stored as unix timestamps and the php 'date' function used to
format output into human-readable form, and mktime used to format the input into stored data. This is IMHO the most accurate way
to store date/time data, and can be used in calculations, making it easier for future mods.

That is the method I have deployed in other php apps that I've been involved in.

Still, data.zip is a vast improvement, thanks to all.

Since I still don't know if this patch is going to be acceptable or applied, I was hesitating to update it, but like many others I need a functional date field, so I am going to go ahead. I'll post it when I get it done.

With reference to #28 and #31, I am in agreement about using the iso format and about not using the mysql date field to store it in.

The iso format is important because a generic date field needs to work for dates earlier than 1970 on both unix and windows systems, and dates stored in unix format will not. (You might want the date to be a birthday or the date that some historical event took place, for instance).

Storing the date in a varchar field makes it work the same across all databases -- you are not assuming any built-in date functions because they vary from one database to another and you don't want any database-dependent code. At least, I assume that is the reasoning. I had to do a database migration one time where both the os and the database type were changed and storing the date as an iso date in a varchar field made the migration much easier.

The most important question is about the database storage type and format since that's what will screw people up if the date module ultimately takes a different turn from the one in my patch. I hope we can at least get a confirmation (and a cvs commit) for using the standard iso 19 character format instead of the not quite standard 17 character format in the cvs version of this module.

Changing status

FYI, robertDouglass is has also submitted a patch with an initial date module UI at http://drupal.org/node/68443 and there is some good relevant discussion at http://groups.drupal.org/node/731.

Without having installed it yet I would say that Karen's work is more complete than mine. I'll try to look at the stuff here and see if my efforts have anything to add. Great stuff! And yes, by all means, jump in on the conversation on groups.drupal.org about the time formats. These decisions will have long reaching ramifications on Drupal's acceptance as a real web application framework.

this seems like a great improvement to the text field for date.

I included the date.zip files in the cck module (using cck 4.7.0). However, I am continuously getting the following error message :

"warning: putenv(): Safe Mode warning: Cannot set environment variable 'TZ' - it's not in the allowed list in /var/alternc/html/e/esperanto/eskdrupal/modules/cck/date.module on line 61."

anyone knows how to fix that?

thanks in advance.

The putEnv error is coming from PEAR. Looks like your server doesn't allow this operation. I thought that it was supposed to be a silent error, but apparently not.

I have been re-thinking this module (especially since nothing has been committed or confirmed yet). I think the only thing that would really keep this module from being committed is the dependence on PEAR Date (as I mentioned in my original post). I need to get a date field I can go ahead and use (and I know others do too) so I am re-working the module to eliminate any reliance on PEAR. It loses some functionality that way, but better to get something that can get committed. There has to be some sort of timezone library to do timezone conversion, so instead of using PEAR I'm going to use the event.timezone.inc file. I'll check whether event is enabled and include a copy of the file if it is not, so the field will work either way.

There is a discussion on groups.drupal.org about whether to use timestamps or iso dates. I still like being able to use iso dates and for the most part the module was written so you can use either format, so I am thinking I could make the date format an option too, in the same way that the number module has an integer and a decimal format option. With that change, hopefully, the module will be universally useable. The only thing it will be missing is some ability to handle pre-1970 dates, but it should be useable otherwise.

It will be a bit of work, but I've got a good start on it and hope to get something posted soon. (I'll also include fixes for the problems that have been reported in this thread).

JonBob, if you're following this thread and you have no intention of using this module or you have something else entirely that you plan to commit, it would be great if you would jump in and say so. It will save me the time needed to update it and keep others from relying on something that won't get committed.

KarenS, I just want to say a big thanks for slugging away at this!

OK, I have something to be reviewed. There are several files in the zip file. You can create a 'date' folder inside the cck folder and put them there or just add them to the cck folder. If you do the first, be sure to remove any date files from the cck folder so there is no confusion about which is which. You can also remove the pear folder, if you used the earlier version of this patch, since this doesn't use pear any more.

The files include:
* date.module - the cck module
* date.css - mostly for the date selector drop-downs
* date.install - the date.module install file
* date_timezones.inc - a copy of event_timezones.inc, used only if event is not enabled
* adodb-time-inc.php - this library will be used if the file is in the same folder as the date.inc file, remove it if you do not want to use the adodb date library and the api will use native php date functions.
* date.inc - the date api, used for date calcs by date.module, but could be also used by any other module

usage example for the api:
* create a new date object:
$date = date_make_date();

* set local value of 2006-05-04T10:24:00 US/Eastern
date_set_date($date, '2006-05-04T10:24:00', 'US/Eastern', 'local', DATE_ISO);

* display the local value using the format string 'm/d/Y H:i'
print date_show_date($date, 'm/d/Y H:i', 'local');

* display the db values of the date object:
print date_show_value($date, 'db', DATE_UNIX); // the unix db value
print date_show_value($date, 'db', DATE_ISO); // the iso db value

* display the date object and all its parts:
print_r($date);

Features:

* date.module now can create two types of dates, an iso date or a unix timestamp

* the date.inc api creates a date object that has both db and local values for a date and timezone info. That object is then passed to all other functions that need it.

* optional incusion of adodb date library extends the valid date range from year 100 to year 3000, without the library it is the usual 1970 to 2038. To keep overhead to a minimum, the library is only included when used.

* actual timezones are used, not offsets, because offsets don't provide enough info to do dst adjustments. the event_timezones.inc file is used to calculate offsets. It works for dst for many common zones, but not all. If event module is enabled, the api uses the event file, if it is not, it uses the included copy of that file. To keep overhead as low as possible, it is only included when used.

* timezone handling options include using gmt, the site timezone, a date-specific timezone (selected when the date is edited), or no timezone handling. The last option will store and display dates exactly as entered, useful in situations where timezone conversions don't work accurately, or when they are just not desired. I've omitted any option to adjust to the user's timezone since we don't know what it is, we only know their offset. That can be extended or worked on in the future if someone figures out a way to make it work.

I haven't yet tried to add in better views handling options. We need the views filters patch to be committed, and perhaps other changes, to do that right.

If you previously used the cvs version of the date module, there is a database change to change the iso format from YYYYMMDDTHH:MM:SS to YYYY-MM-DDTHH:MM:SS, so be sure to back up data files before installing. If you previously used my earlier patch, your data should be OK, but still wouldn't hurt to back up just to be sure. Either way, the settings have changed, so you need to pull your field settings up and make necessary adjustments.

Be sure to clear your cache. If you set up the files in a date folder inside the cck folder, you also need to go to the modules page and enable the date module again to be sure that the path to the module gets updated.

Here is my Review:
I am currently playingaround with CCK 4.7.0 on a fresh Drupal 4.7.2 installation.

Installation is OK.
I installed directly your date_0.zip version of the date field into the subfolder /modules/cck/date/.
The installation is fine. The Javascript Datepicker is wonderful. Thank you for this.

'Unable to set date. iso2arrayerror'
If I want to integrate the date field into a view (view as page with table), it gives the error
'Unable to set date. iso2arrayerror' and does not display the column with the test field.

WHICH VERSION?
I have seen that you use the date.module verision 1.14. If I look into the cvsrepository through the drupal homepage I see that the most current version of date.module is 1.18. So are your additions some kind of 'mini-branch' of the 1.14 version of the cvs date field module? Where should I follow the cck module in the next weeks: cvs (web) repository, feature request post?

Thank you again for the wonderful functionality add-onto the date field. kr, Robert

I'm setting the title and version back to what they were. This is a cvs patch for the date module and has not been tested in 4.7. Theoretically it should work, but it hasn't been tested. If you change the title to make it look like a bug report, no one looking for this patch will be able to find it.

The iso2array is text I put in there so I could tell what date part of the date conversion was failing. You're seeing no field because the conversion failed. If you tell me what values and type of field you were trying to create, I'll see if I can replicate your error. I need to know what type of date field you created (timestamp or iso), what option you selected for timezone handling, the timezone that should have been selected for that option, the value you tried to enter into the field, and the widget type you are using (date selector, jscalendar or text).

And you'd better tell me whether or not you are using the adodb library.

Thank you for the directions about the Project information and Issue information fields (was my first feature request post).

The datefield should be used for a birthdate (only year, month, day)

1. The iso2array error was only displayed for all data nodes that where created BEFORE i activated the date field module (sorry for that, should have seen this earlier)
2. The view column for the datefieldis stillempty (tried all combinations for the CCK field settings)
3. my cck version of content.module: / $Id: content.module,v 1.56.2.3 2006/05/03 12:56:52 JonBob Exp $
(I think I use CCK version 4.7.0 version in combination with drupal 4.7.2, because I tried the cvs version of CCK, which did not work for me with drupal 4.7.2 - white screen of death on admin/modules page)

- type of date field timestamp or iso: Dont know, just added the Date field through the webinterface of CCK
- option for timezone handling: no timezone conversion
- the timezone that should have been selected for that option: Europe/Vienna
- the value you tried to enter into the field: select list, or clicking jscalendar, no manual text entry tested
- widget type: jscalendar (also tried select list)
- adodb library: Yes, I have left the adodb-time.inc.php in the folder /modules/cck/date/

Maybe could you giveme guidlines, which versions of drupal, cck and the datefield I should try?
After reading a few forum posts here, I have the feeling, that some modules functionality broke by stepping from drupal version 4.7.0 to 4.7.2.

thank you for your quick reply and further 'featureshooting', Robert

I think this is probably some old date fields with the earlier format (YYYYMMDDTHH:MM:SS instead of YYYY-MM-DDTHH:MM:SS). Did you do the update.php? I forgot to specifically mention this, but that is needed to change the date format from the older version. Go to drupal/update.php (use your own path instead of 'drupal') and choose the option to update the database. You should see that the date module has an update that is needed. Choose to run it, then come back and see if your fields work right. Be sure to do a backup before you do this!!

I tried to
1. disable the date module
2. performed TRUNCATE cache
3. enable the datemodule
4. run update.php (but no updates are displayedto be needed, also no results or errors are given)
if i run it twice i get 'Call to undefined function: content_fields() in /home/httpd/vhosts/easytouch.at/httpsdocs/total/modules/cck/date/date.install on line 92'

Maybe too much things have been messed up due to the testing, so I will continue testing with fresh setups even to be sure about the versions of everything. kr, Robert

The message 'undefined function content_fields' is the clue. There was a change to the cvs version of the content module that used this new function name. I just checked and this change was not made to the 4.7 version of the content module. This means you definitely do need to be using the cvs version of cck for this module to work. Other than that, I think the 4.7 version would have been OK.

On the database update. It sounds like you started creating new fields (with the new format) while you still had old fields with the old format, so you data is probably goofed up. The best path from here depends on whether or not you have a lot of data already entered that you need to save. If not, the best results would probably be from deleting any date fields you already have, making sure they've been removed from the database (using phpmyadmin or whatever), then just create new ones which should get created in the right format.

If you have data that needs to be preserved, you may need to run a script that will check the format and update as needed. I'll take a stab at writing something that could be used for this purpose, since the transition from one format to the other may create problems for others.

@easytouch... try not to change the version number of existing issues (in general)... it messes things up for people who are tracking them. The exception would be in cases where Drupal HEAD gets tagged as 4.8 or something; then the issues that were marked cvs for HEAD would now need to get marked 4.8.

I found a problem in the install script for the database update (this patch has been through several cck database changes, so it has been complicated to keep up). I re-wrote it in a way that you can re-run it and it will only make changes if changes are needed. Upload the attached file to your directory, go to update.php and select the option to run updates. If you have already run the last update to the date module (update #4), you can still select that update from the drop-down list. Then run it. It will not do anything if your database is OK, but it will find fields and columns that are in the wrong format and update them.

And here's a new copy of the zip file with the changed .install file in it.

I'm wondering if it would be a good idea to create a separate project for the date module. Then we could have a cvs repository to store the latest version and set up issue and feature tracking for that module since it's a somewhat complex module that is going to need some debugging and testing. Plus I could go ahead and get updates to the date module committed even if JonBob is not available to do it. Not sure if that is appropriate or not, so I'd like feedback on that idea. I'm not trying to co-opt this module, just trying to find a way to move things along a bit more quickly.

FRESH INSTALL TEST

PHP 4.4.1
MYSQL MySQL 4.1.15

Downloads as of 24.06.2006

Drupal 4.7.2
http://ftp.osuosl.org/pub/drupal/files/projects/drupal-4.7.2.tar.gz
uploading mySQL database content form drupal-4.7.2.tar.gz:/database/database.4.1.mysql

Module Views (cvs, 24/06/2006 - 10:00, 91.21 KB)
http://ftp.osuosl.org/pub/drupal/files/projects/views-cvs.tar.gz

JavaScript Tools
http://ftp.osuosl.org/pub/drupal/files/projects/jstools-cvs.tar.gz

Module CCK (cvs, 13/06/2006 - 02:00, 37.56 KB)
http://ftp.osuosl.org/pub/drupal/files/projects/cck-cvs.tar.gz

rm /drupal-4.7.2/modules/cck/date.install
rm /drupal-4.7.2/modules/cck/date.module

KarenS date module
http://drupal.org/files/issues/date_1.zip
to ownsubfolder within cck module /drupal-4.7.2/modules/cck/date/

DRUPAL ADMIN
- enable modules: content, text, date, optionwidgets, views, views_ui, jstools, jscalendar

CREATE DATE CONTENT FIELD
First Screen: Date (not Datestamp) Field with javascript
Second Screen:
(*) Text Field with javascript pop-up calendar
Granularity: [v] Year [v] Month [v] Day [ ] Hour [ ] Minute [ ] Second
Time format: (*) 24 hour time
Date display: [01.08.2006]
Time display: [ ]
Zone display: [ ]
Site timezone: [Europe/Vienna]
Time zone handling: [No time zone conversion]

WIDGET SETTINGS FROM mySQL table
a:6:{s:4:"ampm";s:1:"0";s:9:"increment";N;s:11:"granularity";a:6:{s:1:"Y";s:1:"Y";s:1:"M";s:1:"M";s:1:"D";s:1:"D";s:1:"H";i:0;s:1:"N";i:0;s:1:"S";i:0;}s:11:"format_date";s:5:"d.m.Y";s:11:"format_time";s:1:" ";s:11:"format_zone";s:0:"";}

CREATE ONE 'PERSON' NODE

CREATE VIEW
http://et.vc/drupal-4.7.2/?q=admin/views/add
warning: Missing argument 1 for views_ui_admin_add_page() in /home/httpd/vhosts/et.vc/httpdocs/drupal-4.7.2/modules/views/views_ui.module on line 386.

RESULT:
The 'Date' column is empty without error messages.

@KarenS: I don't see any problem with creating a separate project for this and I really don't believe anybody would accuse you of anything. It would make the code more readily available for downloading, testing, and would simplify bug tracking. I say go for it.

@easytouch, just to clarify, does the field seem to work OK outside of views? If it is only a problem in views, can you export the view you are using and paste it here so I can see what the view looks like.

@robertDouglas, I am going to give others a chance to respond in case anyone sees a good reason not to do this. If I don't hear any objections in the next day or two, I'll go ahead and start a new project.

@KarenS: Yes, outside views everything is ok (except if I add the field after some datasets of the content type already exists (the iso2arrayerror) - but this is away if I enter all nodes with edit and resubmit them (todays date will be filled)

Find attached my views export.
it contains
- one field text 'Name'
- one field date 'Datum'

Maybe I should try this with Drupal core cvs Version?

I don't think using core or cvs version of drupal is the issue.

It looks like there is a views bug producing the views message (see http://drupal.org/node/70652).

Let's focus first on getting the date field working correctly. After that I'll try to get views working (and that will give merlin a chance to see what might be causing the error message in views).

Are you saying the iso2array error occurs only when you first go to a node that already existed before you updated to the new version of the date module and the error goes away after you save the record? I assume there is no problem when you create a new node, just if you are working with a node that already existed. If so, that gives me an idea where the problem lies.

If you are working with data that was created with an earlier version of the date module, did you run the update #4 before trying to work with the data?

My test at June 24, 2006 - 18:11 was a totally fresh install. I only created one node with a date field. If I enter data everything is ok wile editing the node and vieweing the node. Only in views the column with the date field stays empty.

The iso2array error is only displayed if nodes of a content type of f.e. 'Person' still exist, and after that I add a date field 'birthdate' to the content type. Then the iso2array error is displayed for each node of content type 'Person' where the newly created date field is empty. If i go to each node of 'Person' and edit it, enter a date and close it, then in the node-view and the view-table the iso2array errors are gone. Just the column of date stays emtpy. With the pure cvs version of CCK the views are ok and showing data within date columns.

My only real motivation at this point is the javascript entry possibilty with jstools, to make the use of date fields acceptable by endusers.

Now I tested the case if someone is using the date field of CCK (cvs version) and then wants to upgrade to your version of date1.zip.

1. Using the standard cck date field I created the birhtday field and created on node. Display on Node-view and Views-Table is ok.
2. disable module date, run update.php (no messages)
3. remove date.install and date.module from modules/cck folder (the cck verion of the date module)
AT THE BEGINNING OF TESTING I RAN INTO THIS: (I created the date folderas subfolder of cckmodule,unzipped the karens date field files, and forgot to delete the date.install and date.module file in the cckfolder, maybe your .install file could check this, and display a message, or your date field gets a different name than 'date' as submodule of cck)
4. unpack KarenS version into modules/cck/date/ folder (with adodb as it is)
5. activate module date, run update.php

Now the following message appears (date_cck_cvs was the name I gave tothe cckversion of the date field)
---------------------------------------------------------
ON THE UPDATE SCREEN
user warning: Duplicate column name 'field_datum_cck_cvs_value' query: ALTER TABLE node_content_person ADD COLUMN field_datum_cck_cvs_value varchar(20) NOT NULL default '0001-01-01T00:00:00' in /home/httpd/vhosts/et.vc/httpdocs/drupal-4.7.2/includes/database.mysql.inc on line 120.

The following queries were executed
date module
Update #4

* UPDATE {node_content_person} SET field_datum_cck_cvs_value = CONCAT(SUBSTR(field_datum_cck_cvs_value,1,4), '-', SUBSTR(field_datum_cck_cvs_value,5,2), '-', SUBSTR(field_datum_cck_cvs_value,7)) WHERE SUBSTR(field_datum_cck_cvs_value, 5, 1) <> '-'

---------------------------------------------------------
VIEW A NODE SCREEN (containing one date field)
* Unable to set date. iso2arrayerror
* Unable to set date. iso2arrayerror
---------------------------------------------------
EDIT A NODE SCREEN
warning: Invalid argument supplied for foreach() in /home/httpd/vhosts/et.vc/httpdocs/drupal-4.7.2/modules/cck/date/date.module on line 413.

Unable to set date. iso2arrayerror
---------------------------------------------------
VIEW/PERSON SCREEN
Unable to set date. iso2arrayerror (displayed only 1 time, as I have only one node for testing)
---------------------------------------------------

Next Step: Now I delete the original cck date field from the content type person,
and create a new karens date field.

NODE VIEW gives no errors
NODE EDIT gives no erros and automatically fills the date filed with todays date. If I click on [Submit], the Node View also displays the date correctly,as I have setin the second Widget Screen at creation time of the date field.

Now I go to admin/views and delete the zombie date field from the View Definiton, and add the karens_date field as a new column to display. Now if I view the Views-Table Page, no errors are displayed, but the date column is empty.

As I am only a testing user from the outside of coding - my feeling is that there are two issues:
- handling of migration path, if someone has data entered with the actual CCK date field in CCK cvs version and want'sto upgrade to the KarenS date field.
- Display date fields if they areselected in Views of the Views Module (this could be a views module issue)

I'm abusing the "put this in 'my issues'" thing mostly, but I also wanted to thank easytouch for his very thorough patch review! Excellent job!

making it a separate module is a good idea, but it will cause a lot of «CCK is not cool, because you cannot even add dates» alike comments and thoughts.

I think it is very important we define the OOTB experience for CCK on a short term. What it does, what it covers, and what it does not do.
Bèr

I actually think it is a good precedent to make it a separate module. I'm disappointed to date with the lack of effort that other developers have put into making their own field types and widgets. This date module does both. KarenS, be a pioneer. Make it its own project. I can always be put into CCK later (look at how views_feed just got put into views).

I haven't tested this yet (won't have time until later next week), but I would like to thank KarenS for all the hard work here (and the testers too!).

I really like the ADOdb library drop in for extended date range support (the same solution I suggested at http://groups.drupal.org/node/731).

I am not sure about the advantage of the ISO data field over the timestamp field. I understand that the original benefit was extended date range support, but since the ADOdb date-time library handles this fine with timestamps I can't see why this is needed. ISO storage seems to have disadvantages in that it is harder and slower to query, index and sort than a plain old timestamp. I am guessing about the slower part, but if you think about the data space (8^19 bits for an ISO date-time (at least), vs 64 bits for a PHP float timestamp) it seems an order of magnitude more vast. If someone could point out some reasons why someone would want to store ISO dates this I would be persuaded :)

The other thing with having two separate date types is that it could create incompatabilities. For example module A (that displays nodes from this day last year) works only with ISO CCK date types, whereas Module B (that displays a list of nodes less than two hours old) works only with timestamp CCK data types (OK, this is a forced example, but please bear with me). Now if I want to use both modules for the same content type I am stuck.
I guess the way round this (short of abandoning ISO!) would be to always store both data types, so a module can be sure that the type that is most convenient for them is available.

One last thought is that we might want to think about abstracting some of this so that:
* The core date handling functions could eventually be pushed into core
* The date selection widget can easily be replaced or extended by another module

I also think it would be great if this were part of CCK by default, although I can see that it would be useful to create a project for it too...I guess project.module needs 'subprojects'!

- Owen

Thanks for all the feedback! It's clear we need a better tracking system since there are several different threads/issues here. My main reason for making it a separate module was so we can identify the various problems/decisions and track them as separate issues. I'm really not trying to remove it from CCK, except maybe temporarily so we can iron all the issues out.

Actually, the more I think about it the more I think there are really 2 things here -- a cck date module and a date api. The date module belongs in cck (and requires cck to work), the api could be used by other modules (at least that is the intent), so maybe I need to set up a separate project for the api and leave the date.module in cck and somehow make sure that the api gets activated along with the module.

Grugnog2, yes, I did steal your idea about adodb :-) In fact, I took several ideas from that thread and tried to figure out a way to incorporate them into this module. My goals were:

* Keep at as lightweight as possible by making everything outside of native php date handling optional, and including external files only when used
* Make it as flexible as possible, rather than decide one best format, let the user make that decision and just provide a way for them to do it

I think there is a role for an iso date option. Iso dates are especially nice when you want less precision -- a year and month without a day, or a year only. With timestamps you have to force a complete date, even if it's wrong. So iso dates are really nice for historical or geneological dates, for instance.

Karen, I agree it makes sense to create a new project for this, if only as a temporary solution until JonBob responds. As someone else mentioned, it can be always be folded back in to CCK later as the default CCK date field if approved. In the mean time, it would make it much easier to move things forward, for you and everyone trying to follow this. Besides this thread is quite long enough now :-)

I just upgraded a small test site from a previous version of Karen's date code and everything went smoothly. I did have to manually select update #4 and had to go back to the configure page for each of my date fields to reselect the appropriate date and time display settings. But the few things I checked appear to be working fine.

@KarenS (or anyone else who know), could you please give me a short explanation of the various timezone handling options? Most (probably all) of my date/time fields are for local events, so I'm particularly interested in making sure I that the correct times are displayed as daylight savings time comes and goes. (i.e. If I enter a June event in Feb, etc.)

Thanks again, Karen for all your work.

It seems best to create a separate project, if for no other reason than to get issue-tracking working, so I have done so. The project is at http://drupal.org/project/date, so please feel free to go there and open issues, feature requests, or whatever. I just posted the files in the zip file, making no other changes yet. You can see them in the cvs repository and I assume the download file will appear later. I'll start following up on the things reported so far over there.

Anyway, let's move this thread over to http://drupal.org/project/date.

Closing this issue since separate project exists.