Time Is a Flat Circle and Microsoft Broke It

You know, I was thinking about time the other day, and how it's one of those things we all take for granted, like the air we breathe or the fact that our computers will probably boot up most mornings (and when they don't, that's not a crisis, that's Tuesday in IT, where every day is a fresh chance to discover that the thing you fixed yesterday has quietly un-fixed itself overnight). Time is a human construct, a way of slicing the continuum into manageable chunks, and yet it rules our routines with a fist that never gets tired. We're all slaves to the clock, in one way or another, and when the clock starts to malfunction, well, that's when the fun begins. Or the fire. Usually both.

Microsoft's recent foray into timezone management has been a fascinating case study in the complexities of time and technology, by which I mean they broke time in Canada. Not metaphorically, not in the "does anyone actually know what day it is" way that hits around the third week of a project. They broke actual time, the kind that tells your calendar when the meeting starts and your recurring Thursday standup whether it's still Thursday. Something they pushed out mangled timezone handling for Canadian users across Exchange Online, Power Automate, SharePoint, Power Pages, and probably three other products nobody mentions because they're too embarrassed to admit they still use them. The official fix, the published guidance from one of the largest technology companies on the planet, is to pretend you live somewhere else. Bogota. They're telling Manitobans to set their timezone to Bogota.

Sit with that. A company with quarterly revenue somewhere north of sixty billion dollars looked at a timezone bug affecting an entire country and said, what if we just lie to the computer? And somewhere in a cubicle in Redmond a program manager wrote that sentence down, and someone else approved it, and it went into a support document, and now IT admins across Canada are configuring their systems to say they're in Colombia, and the systems believe them, because the systems don't actually know what time it is. They never did. They were just told to believe whatever the timezone setting says, and the timezone setting is now a work of fiction. It's the old joke about the guy who asks the librarian for books on Pavlov's dogs and Schrödinger's cat, and she says it rings a bell, but she's not sure if it's here or not. That's the whole situation. The systems are ringing a bell and they have no idea where they are.

Here's what gets me. I work IT. I have spent a significant fraction of my adult life in the gap between what a system is supposed to do and what it actually does, a gap engineers call "unexpected behavior" and the rest of us call the reason I'm drinking on a Tuesday. Timezones are one of those problems that look simple from outside and reveal themselves, once you're inside, to be a nested horror of geopolitical history, regional exceptions, legislative whimsy, and the fact that Saskatchewan just decided one day it wasn't going to do daylight saving anymore and everyone shrugged and let it happen. But Microsoft is not some scrappy startup that just found out timezones are hard. Exchange has existed since the late nineties. They have had time. They have had decades of time.

And the remediation plan, the thing they're actually shipping, is a PowerShell cmdlet. For non-recurring meetings only. Arriving "later this week." Recurring meetings? "In development." No ETA. SharePoint On-Prem? November 10. Power Pages server-formatted dates? December 12. They broke time in October and the fix for some products lands in December, which is a longer gap than exists between some Canadian provinces' daylight saving transitions. The bug outlasts the season. We are being outlasted by a calendar defect.

The deeper thing, the thing I keep circling, is what this reveals about how these platforms actually function. We talk about cloud services like they're pristine engineered systems, clean lines and service level agreements and status pages with green dots. Underneath that presentation layer is a pile of decisions made by people who left, sitting on decisions made by people who also left, wrapped in interfaces designed by people who have since moved to other teams, and the whole thing holds together because at some point someone wrote a script that pretends Manitoba is Bogota and everyone agreed not to look too closely. This isn't a Microsoft-specific problem. This is every enterprise stack that has survived long enough to develop its own archaeology. You think your bank's core system makes sense? Your bank's core system is held together by COBOL and prayer, and the prayer is doing more work than the COBOL.

But there's a difference between knowing this is how things work and seeing it confirmed in a support document that says, with corporate calm, that the recommended action is to change your timezone to Arizona, which doesn't observe DST either, so it's "functionally equivalent" to Saskatchewan, a phrase that sounds reasonable until you realize it means we can't make Canada work so we're going to gaslight the calendar into thinking you're in the American Southwest. That this is a published, sanctioned recommendation and not a forum post from some poor admin at 2am tells you everything about the distance between how these systems are sold and how they're actually kept alive.

We sold the world on cloud. We said it would be simpler. No servers, no patch Tuesdays, no guy who knows where the bodies are buried. Just put it in the cloud and the cloud will handle it. And the cloud handles it by telling you to move to Bogota.

I think about the admins reading that guidance. The ones with calendars full of recurring meetings who now have to rebuild every occurrence by hand, because changing the timezone resets moved instances back to their original times, which means every adjustment anyone ever made is gone, poof, because Microsoft's timezone fix doesn't understand that "fixing" a recurring meeting by reverting everyone's manual corrections is not a fix, it's a punishment for being organized. I think about the admin who has to explain to their CFO why the budget review now shows up an hour early, and the answer is because Microsoft thinks we're in Colombia, a true sentence a person has to say out loud, at work, with a straight face, while the CFO waits.

This is the stuff that doesn't make headlines but makes lives. The grinding, Tuesday-afternoon, I-became-an-IT-professional-to-avoid-nonsense-and-now-the-nonsense-is-the-job kind of lives. The timezone bug gets patched eventually, December probably, for the products still waiting, and then it fades, and the next thing comes, and the one after that, and nobody remembers the week Manitoba pretended to be Bogota except the admins who lived through it, who will remember it the way you remember a bad winter, not with anger exactly but with the specific exhaustion of people who know the system that failed them will fail again in a new way and the solution will always, always be stranger than the problem.

The work continues. The kettle goes on. Bogota awaits, and the calendar believes.