Update breaks when date module is in a sub-directory

Same for me... and the path seems very very long…
Fatal error: Call to undefined method DateObject::validGranularity() in /sites/all/modules/date/date/date/date/date/date/date/date/date.field.inc on line 313

You apparently have a corrupted installation. Any time you see something like this it implies that you have something like one version of date installed inside another.

Empty the folder completely and re-download.

There might be a bug in that feature. If you can reproduce it, you should post a bug report.

I've also updated all my d7 modules with the new update module, but it's only happening with date. I think it has something to do with the fact there's a "date" folder inside the "date" module folder. I'll search the issue list to see if someone has already seen that bug.

I'm geting the same error at a different line while attempting to create a date programmatically:
Undefined property: DateTime::$granularity File ~/public_html/sites/all/modules/date/date_api.module, line 1179(

This occurs on with the 1/6 release of 7.x-1.x-dev

I've verified that i don't have multiple nested date folders and cleared my cache...

The recursive updates occur because the date sub-module is in a subdirectory date of the date module package. See http://drupal.org/node/986616 for reference to other modules with similar issues.

Ugh. Moving files and directories around will break every installation. The updater should be smarter, but it won't get fixed so I guess I now have to re-organize the files. That means I have to make a new branch and hope everyone figures out what is going on and cleans out the old files before making the switch.

@KarenS: I think you'll be ok renaming the files - most people use either Drush, which in v4 can correctly remove the old files before importing the new ones, or manually by removing the old files before adding the new ones, I'd say there'd be a very small number of people who wouldn't fall into one of those two camps.

I've already had several reports of borked updates and I'm not clear on which files need to be renamed. And renaming files always leads to other reports of bugs from people who don't remove the old ones.

The rule that the Updater works from is that the main module for a given module package should be at the module's root directory, e.g. for the "Date" module the date.module files should be in the top directory.

I expect a rash of problems from this from people who don't clean out the old files in the old locations, but I've re-organized the files.

Many thanks KarenS for the update.

A couple quick notes on my upgrade experience with the 1/15 build.

As with the previous version, it creates a new date sub-directory when using the upgrade module. Therefore I cleared the old date directory out and downloaded the new. I gather that with the re-organized directory structure all future updates will go as expected.

After updating the directory manually, I received errors about bootstrap being unable to find date_plugin_display_attachment.inc. A drush cc all repaired this and I'm back up and running.

Hope this helps others working on this!

The error reports are starting to roll in, as I expected. Moving files around is a nightmare for a maintainer because many users will expect hand-holding while they sort things out, I really really didn't want to have to do that.

FWIW I just did an update and it worked flawlessly: no nested date directories...

It seems to me that the only people who will encounter errors are those who started with a version prior to yesterday. Once that's cleaned out everything works ok.