Time zone ignored in iCal invites

Question

Recently, maybe since the timezone update, iCal has not been processing the time zone of meeting invites that I receive from Exchange users in my company. It is ignoring the time zone, for example an East coast user sends me an invite for 7pm EST, but I receive the invite as 7pm PST.
I just noticed this problem today but it could have been since the time zone update. I'm a long time user of iCal / Mail, normally I don't have this time zone issue.

Answer 1

Issues like this have been tossed around for a relatively long time, and those beset by them often are prone to point fingers at just about anyone. Much of the evidence offered is incomplete, or even contradictory. I've tried to follow this issue and others like it for some time, and—though, like most others I have encountered, I remain somewhat dazed and confused—I have come to these basic conclusions:
• the issue relates somehow to TZID, the global—but, not globally defined and therefore standardized—time zone identifier
• the heart of the issue appears to reside with some of the many releases of Microsoft's Exchange Server software
It's relatively easy to point the finger at Microsoft, as the notifications which display this behavior seem to originate from domains which run an Exchange Server of one variety or another. But, it's not that simple. Some report that invitations issued inside work, but those same invitations sent outside do not. Some report that patching the Exchange Server corrects the issue, but it's unclear if a specific post-SP2 patch exists to address the issue. Some report that Outlook Web Access users are affected, but not Outlook users. This may simply be because OWA and Outlook users 'get' their time-stamps from different locations, which do not use the same time zone definitions.
I think that you're on the right track examining the source data, but I think that it's the data itself that is the problem—specifically the TZID value, or a combination of that value and other information in the file—that raises the issue.
I don't see much evidence that the problem lies with the current release of iCal, or is caused by the DST patches present in Mac OS X 10.4.6 through 10.4.9, the various security updates or the DST update released by Apple.
The future release of iCal under Mac OS X 10.5 will be CalDAV compliant, and the CalDAV participants are working diligently to prevent just such problems, by standardizing such values as TZID. Microsoft is late to that party, although is now participating as I understand it, suggesting once again that the root of this problem is likely one or more Microsoft products, including Exchange Server.
One challenge with correcting the problem is defining it, and another clearly is working through the many varied iterations of Entourage, Outlook, OWA, the Exchange Server product line, and being sure that applied changes to create problems for others, like an organization's Blackberry and Windows Mobile users.
It would seem incumbent upon an organization's information technology staff to isolate, identify and correct the issue, and not upon users. That might be a challenge to achieve, however, if the majority of users in an organization do not seem to be affected by the problem, no matter how prevalent the problem might be, and how incorrectly an Exchange Server might be operating, if indeed it is.
Further complicating this is the unfortunate change to DST rules which recently occurred, and the requirement to apply changes to Windows XP and earlier along Mac OS X and OS 9 computers, Palm devices, Windows Mobile devices, mobile handsets and the server components which support them. While that issue isn't at all a likely component of this problem, they unluckily have appeared in some organizations almost simultaneously, making a possible link somehow a foregone conclusion, thus only adding to the confusion.
Where the offset is just one hour, as contrasted with the twelve hours reported by one poster, the immediate and logical conclusion is to assume that it's a DST issue. It likely is not.