modifying "Field settings" with data in database

You will see the same restriction on all fields, not just date fields. You can't alter the field settings after there is data.

If you want to make changes like this using scripts, you're on your own. If I provided scripts to do that I would also become responsible to fix all the things they might break. If you study the Field API and the Date API, you might be able to figure out how to alter the settings in the database, then you would have to run batch scripts to update the data to match the new settings. It's quite tricky to alter the field structure after its been created because the data no longer matches the settings and you can end up with lots of unexpected consequences while you try to get them aligned.

A better path would be to create a new field with the settings you want, then use a script, or something like the Migrate or Feeds modules, to copy the data from the old field to the new one.

What is funny is that the message makes you believe you cannot make changes. This is not true. You can still go ahead and edit the field setting and make the changes to capture your new data types. Think of it more as a warning instead of a "cannot do". Just be aware that now you will have inconsistent data in your table(s). You still need to fix those yourself.

Well I take this back. It turns out it is not always the case. I think we are S.O.L in this case.

Just for those daring enough to try to actually change some things with data existing in the database (if, like me, you don't want to have to create a new field/field id, then migrate your data, then update your custom code to use the new field id for everything, and delete the old field...), here are a few tips:

• Do everything on a development site/database. Don't do anything on the live database until you know and re-check that it all works. Data loss could result if you do otherwise!
• You will need to make sure you update the information in the field_config table, and add or remove columns (using db_add_field() or db_drop_field()) to the field's respective 'data' and 'revisions' tables.
• You can simply use a db_query() to select the data field from {field_config}, and use PHP's unserialize to get the data into an array. Make the necessary config changes to this array, then update the field in {field_config} by re-serializing the values using serialize().
• To help make things easier, do create a new field exactly as you'd like it on a development site, then use field_read_field() to inspect exactly what Drupal knows about that field. Do the same on the old field, and keep making adjustments to the old field, then comparing, until you know that Drupal's seeing the same field structure.
• This is not for the feint of heart, as was hinted at in #1. For your circumstance, it may be better to just create a new field and migrate the content. In my case, it was not.

One Method Could Be To Export and Re-Import the Data

1. Create a new field that satisfies your needs.
2. Export all the data from the original field that you no longer can edit.
3. Import all the data from the original field to the new field.
4. Delete the original field.

I wrote a tutorial explaining how to do this.

Do this on development site, not recommended on production sites.
Case : If the backend structure of you new field is the same as that of the old one
Step 1 :
Backup sql table of the field see machine name to target the exact table


Step 2 :
Create a new field and restore the backup to the table of the new field see machine name to target the exact table

#6 is probably what you need