"There is always one time zone in which the event won't be adjusted. Just use that."

I agree with everything except I would modify that statement to be "There is always one location in the which the event won't be adjusted. Just use that."

It seems like people are assuming time zone is fixed when it can change. The fixed point is the location which is used to determine the time zone.

Natural events are trickier because they have different assumptions than human created events. UTC is probably best for those.

You're correct, the relation between time zones and locations isn't fixed. Unfortunately the time zone databases don't have enough granularity, you're forced to choose the nearest location that shares your current time zone.

I do love picking Minneapolis or Chicago when I want a ND location (look at North Dakota in the TZ database, we have some funky stuff going on). Looks like this question has some API for that http://stackoverflow.com/questions/16086962/how-to-get-a-tim...

No no no--you will add a lot of hairball code if you persist in not UTC.

For the virtual meeting, you just localize the time as they query it--this will make your life vastly simpler when, for example, querying over an interval or what have you.

UTC is the right answer.

Did you read the article? A specific case was presented where persisting in UTC simply won't work.

I still believe that UTC is useful as an intermediary, and persisting in UTC can work if all your times are in the past and all your conversions are done with an up-to-date rule list.

Yeah, read the article. Considering new house rule of UTC for present and past, wall time (?) for future.

Person I was responding to gave bad reasoning ("Pick the timezone that matters most") instead of echoing what the article said.