With test sties, the date showing up in search results, do not match the date shown when you view the node.
e.g. this is one:
ASI using Drupal
Story - Dries - Dec 19 2008 - 5:35pm - 1 comment - 1.2849901
If I view it directly, the time is 5:15 pm.
If you look here:
http://api.drupal.org/api/function/template_preprocess_node/6
http://api.drupal.org/api/function/theme_node_submitted/6
core is using the "created" date, not the "changed" date for display. However, apachesolr is using changed.
However, core uses the changed date OR the last comment timestamp in
calculating search relevance:
http://api.drupal.org/api/function/node_search/6
So, I guess this is why have the changed date in the index. We should, probably, be indexing the created, changed, and last comment dates separately.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | gmdate_fix.patch | 414 bytes | webrascal |
| #2 | date-problems-350330-2.patch | 5.97 KB | pwolanin |
| #1 | date-problems-350330-1.patch | 3.42 KB | pwolanin |
Comments
Comment #1
pwolanin commentedhere's a possible start on a fix.
Comment #2
pwolanin commentedmore complete patch
Comment #3
pwolanin commentedcommitting the above to 6.x for testing - but needs more input
Comment #4
webrascal commentedI've had success with the last patch and the date fields themselves are matching up much as I'd expect them to, though I strongly suggest using the attached patch as well.
We were experiencing double timezone manipulation which for us meant we had node creation dates set into the future. Essentially the solr indexing process was applying the appropriate server timezone change to the GMT dates as they were processed.
This of course meant that when the dates came back out during a search Drupal would apply the timezone manipulation as appropriate thinking that the timestamps it was dealing with were GMT, which they weren't. For us here in +13hours land that meant trouble.
Quick and simple fix, but something to watch out for in future thanks to php's date function being a little too helpful.
Comment #5
pwolanin commentedThanks for the patch - looks right in that we should be storing the GMT date (as the equal representation of the unix timestamp) rather than one that might have been manipulated.
Comment #6
vladimir.dolgopolov commentedI've tested the patch from #4. It works well with UTC.
I've noticed the field 'last_comment_or_change' is never used.
Comment #7
pwolanin commentedit's true that 'last_comment_or_change' is never used at the moment, but we wanted to index it so that we could easly add a sort or boost based on this field later without requireing a re-index.
Committed the patch to 6.x - thanks!
Comment #8
pwolanin commented