You haven't actually read the article have you?

> It's better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying/editing.

That timezone conversion is the problem, the UTC offset of a physical location can change drastically with surprisingly little notice. You schedule a meeting on your calendar for 10AM, it's stored as XUTC, the rules changes now your calendar tells you your meeting is at 11AM local time, you've missed your meeting (because you were physically meeting your VC who uses their own calendar which does not have that specific issue).

And being an hour off is pretty tame, back in 2011 Samoa flipped across the international date line, if you had scheduled a meeting after the flip and it was stored in UTC but edited or viewed in local time you would now go to it a day off.

I don't think you understood the described problem with storing the time in UTC. In the example in the article it is assumed and your software gets the timezone update. But because the meeting is stored in UTC, it displays the wrong time.

The reason it works for you is because you schedule in UTC. That's great, but for people that don't schedule meetings in UTC, you are vulnerable to the problem described if you just save the time in UTC.

Do you schedule meetings with your dentist in UTC too? I'd wager that most meetings are not scheduled in UTC.

Until today, I thought the way you did and advocated the same principle whenever I could. This article changed my mind very quickly, all with a simple easy-to-understand example.

For any event you generally have a location or time zone that the event time is specified in. If that's UTC then great, you don't have a problem. Most people don't work in UTC; if the time zone laws change, then the event time in UTC will change too.

"It's better to simply store the UTC time of the event, and nothing else."

The whole point of the article is that /you cannot know with certainty the UTC time of a future event/ if you are starting with a wallclock time in a particular location.

In this article, a 10:00 am meeting in Santiago has one UTC value prior to a new law, and a different UTC value after the new law.

If you are saying everyone should "schedule in UTC" like you do, good luck imposing that on the world!

When I create a repeating event in Calendar for Mac in a Google calendar, the scheduled time changes after a DST transition. Really annoying.

You missed the whole bit about the timezone rule changing in between when the event was last edited and when it was displayed.

I think you're missing the point of the article.

What he's getting at is that timezone rules change, so the function to go from local to UTC when you save the meeting is not the same as the function to go from UTC back to local at the time of the meeting.

I do get the point, but simply preserving the local time isn't the right answer. I'd argue that when you change your local timezone offset, then your future schedule is indeterminate and all events have to be reverified. What if the event is for an international flight -- is it still leaving or arriving at the same local time? How about that standing 9AM meeting -- is at 9 because of the corporate office in a different time zone calls in, so your local time breaks their calendar?