date browser broken with latest update

Just realized that that error got converted by the Drupal filter. Just in case it's relevant, here is another try. I'll insert spaces after &s so they don't get converted.

Unknown column & #039;timezone_name& #039; in & #039;field list& #039; query: SELECT DISTINCT timezone_name FROM users ORDER BY timezone_name in ...includes/database.mysql.inc on line 172.

If you don't have a timezone_name column in your users table you have a very messed up situation. That column was added when you first installed the date API and there should be no way you can get to the timezone update without that column already being there.

Can you inspect your database to see if such a column exists in that table. If not I need more info about exactly how you installed and/or updated your site to figure out how you could not have that column in your database.

I checked, and I have a timezone column, but not timezone_name. I should add that I've gone back to version 5.x-2.0-rc for the time being and everything seems to be functioning fine with the date module other than (obviously) the situation I described back in this other thread: #232820: date browser block display bug. I'm not sure if I should try updating again or not. Should I have timezone_name in version 5.x-2.0-rc as well? If so, then something is wrong, but I can't tell what.

You should have had that column in every version of the Date module, going all the way back to its very beginning. I have no idea how you could have the Date API installed and not have that column and this is the first time I've ever heard of this problem. Did you update your database manually or do something else other than the usual method of installing it on the Modules page?

Any way, you cannot use the Date API or any module that depends on the Date API without that column. It can be empty (and often is if the user hasn't set it) but the column must be there.

If you have access to your database, you can add it manually with something like:

Thanks. I did the manual database fix and re-updated. Everything seems to be fine so far.

OK, good.

Automatically closed -- issue fixed for two weeks with no activity.

I just ran across this same issue with a new install using 5.x-2.0-rc7. There was no timezone_name column in the users table. Once I added it manually, things seemed to work fine, but it was not installed inititally.

The column is added in date_api_install(). There is no way you can have a new install that doesn't add that column. The only way this could happen is if you are adding it to a site that had Date API installed already so that the install hook is not called, but even then the column should have been already there.

Unless you can describe a scenario where you can reproduce this in a completely new install, I assume you had bad information in your database somehow.

There are thousands of sites using this module and these two reports are the only ones I've ever had that the timezone column was missing, so I have to assume it's not actually a problem in the module but instead a couple instances where the database got screwed up.

Automatically closed -- issue fixed for two weeks with no activity.

For what it's worth, I had the same problem.

hi there,
i stumbled now, after a while, apon this post.
tried to migrate my drupal6 installation into a fresh one when it didn´t work cause of the mismatch of columns.
had no idea where this column came from and what it´s purpose was.
in general i´m wondering:
- why does a custom module add a column to some of the "core" tables?
- why do (nearly all) module creators do not add to their documentations on the project page which tables or columns they do add or manipulate, and for what purpose?

how was that phrase again about providing poor with fish or better teaching them how to fish ... ? ;)

for the nerds this all might be of minor importance cause they might be able to read in code and databases like in a comic book.
but "ordinary" people like me have much of a hazzle with such things.

nevertheless: thanx for your valuable modules and your support here :)

lesson learned: always install date before trying to migrate users to a fresh install;)