I'm using the latest Orage, compiled with the internal libical (so I don't have the issue in bug 7929).

I'm finding that Orage is displaying events on days in the month view based on the recorded date, without considering how the timezone will affect the day it lands on. This generally results in most events recorded in UTC appearing on the next day.

Once the event is selected for a given day, it THEN is processed for the timezone, so the time is correct, and the event is sorted before all of the events that actually happen on that day.

Looking at the ics file, here's an event that displays a day late in the month view for me:
BEGIN:VEVENT
UID:blahblahblahblah@google.com
DTSTART:20120126T010000Z
DTEND:20120126T013000Z
CREATED:20120125T081953Z
DESCRIPTION:
DTSTAMP:20120125T193052Z
LAST-MODIFIED:20120125T081956Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Stuff
TRANSP:OPAQUE
END:VEVENT

The calendar also has a VTIMEZONE section, and the timezone is set to America/Los_Angeles.  The system is also set to America/Los_Angeles.  Note that since the event is in UTC, the day shows up as one day later on the month view (1/26), instead of the true America/Los_Angeles date of 1/25.

This same logic error can also be found in the day view.  For the above example, if both 1/25 and 1/26 are visible in the day view, the event shows up where it should.  However, if you scroll the view such that 1/26 is not shown but 1/25 is, the event disappears from the 25th (since events nominally on the 26th are culled out).

I would recommend modifying the event culling to be two steps:
1) select all events on the target day/day range plus one additional day before and after (you can't select just one after or just one before, since the event might have a timezone that is relative to yours in either direction).
2) process time zone information for the selected events
3) select the events that actually fall on the correct day

Otherwise, Orage's time zone handling seems to be working well with the internal libical.  In the longer term, perhaps somehow convincing libical to not do any time zone conversion whatsoever would improve the compatibility with shared versions of libical?  That's a topic for the other bug, however.