Offset between stored and indexed date

Also having the same issue, and I can confirm the fix worked for me...

The 'UTC' parameter is included there because dates stored in Solr are always UTC dates. It also makes sense: if users on a site can set their timezone, having the timezone not as a fixed parameter would lead to a complete chaos in the saved values, since the values won't always be indexed and retrieved with the same timezone settings. So this workaround, while tempting in its simplicity and working on smaller sites, is definitely not the solution.

Some research lead me to the real cause of the problem: since Facet API is sadly highly Solr-centric, it always uses UTC for handling dates internally, thus leading to the wrong display values. I've tried to figure the system out enough to come up with a patch, but it's a very complicated mechanism and I wasn't able to solve it completely. The attached patch is what I have so far – the problems when filtering on a date are gone, but there is some weird behavior due to DST (cursed be its name). I'll try to take the time to complete the patch some time in the next weeks, but if someone else could figure it out that would be highly appreciated!

I encountered the same problem and I worked on it unfortunately without having seen your patch. We came up with a very similar solution. I solved the DST problem, so I am uploading my patch. I put the additional code in the module file since I thought it could be of general interest.

For things to work perfectly, you will need to patch facetapi too: https://drupal.org/comment/8265709#comment-8265709.

Thanks a lot for jumping in here and helping with fixing this! It's really a puzzler so I'm very glad someone's helping.
However, I don't have the "Date API" module installed and for me, your patch isn't working at all. The 2012 filter runs from [2011-12-31T23:00:00Z TO 2012-12-31T23:00:00Z] and has "2011" as its label. It then displays the following hierarchy upon clicking:

(-) 2011
  + September 2012 (21)
  + April 2012 (18)
  + August 31, 2012 (18)
  + March 31, 2012 (18)
  + July 2012 (17)
  + June 2012 (17)
  + October 31, 2012 (16)
  + May 31, 2012 (14)
  + November 2012 (13)
  + February 2012 (11)
  + January 31, 2012 (7)

(The links, again, really filter for the month after the one displayed.) It's about the same for lower levels, too. Applying [#8265709-5] only changes the labels which have "31," inserted back to normal, but changes all others to just display "2012" as the whole label.

If it is really working correctly with Date API installed, please try to emulate your code without using that module. A proper solution would be brilliant!

On another note, there were several comment style violations in your patch, a revised patch is attached.

(Also, note that the "Related issues" field is (more or less) bi-directional: you don't have to add a relation to both the involved issues, those will then just be listed twice (under different headings).)

In any case, thanks for your effort! I hope you'll manage to solve the last problems with it!

I setup a clean site without date_api and genreated content using devel with random dates over the last year. I got some of the problems you reported, but not all. In particular I did not see month facets displayed as years.

I realized that one of my custom modules played an important role in displaying the facets correctly, so I ported the relevant code into the patch.

Also I got rid of the date_api dependency after I realized Drupal itself do set the timezone information.

Everything seems to work well on my test site.

Thanks for revising your patch!
However, the new patch only fixed some of the problems. The labels are now never off by a [unit] ("2011" instead of "2012", "September" instead of "October", etc.), so that part is fixed. However, the facet links that got an infix "31, " with the previous patch now get an infix "1, " instead (but, as said, at least display the correct month name). When applying the Facet API patch, the display again changes to fix the appended days but changes all other months to the year:

(-) 2012
  2012 (21)
  2012 (18)
  April 2012 (18)
  September 2012 (18)
  2012 (17)
  August 2012 (17)
  November 2012 (16)
  June 2012 (14)
  2012 (13)
  2012 (11)
  February 2012 (7)

I can't really tell where this is going wrong, sorry.
However, since we are now circumventing the whole Facet API date handling anyways, maybe the easier and better fix here would be to change the whole thing. E.g., instead of using the raw Apache Solr filters in the URL (which is aweful UX anyways), we could just use, e.g., f[0]=created:2012 for years, f[0]=created:2012-10 for months, etc. That way, we'd pass the granularity information right back to the mapping function, removing the need to parse the Solr filters again (twice, actually) and get much, much nicer URLs.

Initially, we just didn't do this so we could use the Facet API code. Now that we don't do that anyways, I don't see any reasons not to do this. Especially since this time zone/DST bug seems rather hard to fix, and would probably be much easier to handle if we'd just get the range we want to filter by right away.

If you want to give that a try, that would be awesome! (Of course, if you otherwise manage to solve the issues here, that would be also great, and I'd commit that just as happily.)
Otherwise, I'll try to look into this when I have the time – which might be March, though, due to an upcoming vacation.

OK, I hope it's warranted but I'm really proud of this one. The attached patch fixes practically everything that is wrong with current date facets handling – the error mentioned here, some avoidable performance drains and the much too complicated code (though it necessarily remains a bit on the complex side). It took me quite some time, but it was worth it.

So, please give it a try and/or a review and I hope we can commit this soon!
(The Facet API patch is not needed anymore as we are now almost completely separate from Facet API's (completely Solr-centric) date facet handling.)

Using search api db, youch

Cleared cache and all is better and fixes the wrong year thing

Thanks for testing, good to hear it works!
Yes, please clear the cache after applying the patch, Facet API caches its facet information and that's would really mess up the display in this case.
Anyone else want to test?

Works for me too. My facet on a custom date field with a year granularity classified the content one year before because of timezone. I updated from 7.x-1.6 to the last dev with this patch. It seems to work like a charm now. Thank you!

The patch (#11) fixed the offset problem on my site too. Thank you!

However, I had to make 2 modifications so that it works for our site.
1. In query_type_date.inc, I added 1 line $value = "$value"; before the comparison if (!$value || !ctype_digit($value[0]))
2. In search_api_facetapi_map_date(), I added code to allow overriding 'format callback'

I attached a modified patch. This is the first time I created a patch so let me know if it works. Thanks!

Thanks a lot, good catch and nice idea!
Committed.
Thanks to everyone who helped analyze and test!