function calendar_fields has incorrect behaviour

In calendar.module, function calendar_fields shows incorrect behaviour. Displaying story nodes in a calendar by creation date triggers the bug for me. I'm using 5.x-1.x-dev from 2007-Jun-22 (calendar.module v 1.20.2.71). A short analysis and workaround for non-CCK situations follows.

So, what should this function do? I gather this: return all fields that represent a date. These fields can be used to put nodes in the calendar. Special care taken to avoid duplicate fields for begin and end nodes.

And that's where I think the trouble is introduced. Let me first show some debugging results. I print $name and $event_field_processed for every iteration through the _views_get_fields() array, at the end of the if ($type) code block:

name=comments.timestamp, event_field_processed=, tmp[1]=timestamp
name=node_comment_statistics.last_comment_timestamp, event_field_processed=, tmp[1]=last_comment_timestamp
name=node_comment_statistics.last_changed, event_field_processed=, tmp[1]=last_changed
name=event.event_start, event_field_processed=1, tmp[1]=event_start
name=event.event_end, event_field_processed=1, tmp[1]=event_start
name=node.created, event_field_processed=1, tmp[1]=event_start
name=node.changed, event_field_processed=1, tmp[1]=event_start

you can see that no fields are added anymore after event.event_start was encountered, because $event_field_processed has been set to one. This results in the node's fields not being added to the list. That the comments timestamp is included, is merely a by-product of it being alphabetically before event.

Please also note line 321 saying $event_field_processed == TRUE, which look suspicious.

I think this function needs to be rewritten, not using a single $event_field_processed, but a separate check for every field that may have begin/end times (in the case of multiple CCK fields).

I'm all too new to this (I have no idea about CCK), otherwise I'd have attempted to create a patch. So please bear with me if I'm completely wrong on this.

For now, I'm using the attached patch as a workaround; I'm not using CCK at all though.