Isotoma Limited

For one of our current projects we have a requirement for a portlet very similar to the ‘recent changes’ portlet, but with some AJAXy filtering and sorting. To ensure that I was getting the behaviour I wanted while I was still mucking around I had written a script that auto generated some content to appear in that portlet; my intention being to use that to make sure that my sorting and filtering were behaving as expected.

Unfortunately sorting on the last modified date didn’t work. It just didn’t. I had copied the code to get the content from the recent changes portlet lock, stock and barrel, including the sortorder and sorton parameters, so I was at a loss as to what was going on.

My confusion only grew when I started to browse the modified index. The dates displayed did not reflect the dates that the objects had actually been modified. In fact everything was resolutely stuck in late January 2004.

I started looking at all of our other portals. The values in their modified indexes were the same. All their dates were somewhere in late January 2004 too.

Investigation of the DateIndex in ./Products/PluginIndexes/DateIndex of my Zope installation showed the following reason for both behaviours.

The DateIndex uses an internal representation of dates, rather than a DateTime object. This format is used because a) DateTime objects are large both on disk and in memory and b) they provide too much granularity for most date based searches. Therefore instead of using DateTime objects an integer value representing an approximation of minutes since year zero is used. (Remember that these values only need to be in order and unique. They do not need to accurately represent the date, so this value is perfectly suitable.)

That explains the lack of sorting. Because my content was all created in the same minute (by my script) it had no sort order, as the index is not that granular.

The screwy dates when browsing the index are similarly explained. The dtml that generates the index browser (./Products/PluginIndexes/dtml/browseIndex.dtml) creates a Zope DateTime instance from the DateIndex value (so that nice string representations of the date can be printed to screen), but the DateTime constructor assumes that any integer passed is a UNIX time stamp (seconds since the epoch) rather than a DateIndex internal representation (minutes since year zero).

So don’t panic when your DateIndexes all look screwed, it is only presentation.

(In case you were wondering, 10:58:58 on 8th January 2004 is the time when seconds since the epoch and DateIndex’s minutes since year zero are equal)