Calendar-based time intelligence in Power BI and Fabric Tabular models has been available since September 2025, and it brings real power to custom calendars. But with that power comes a set of hidden pitfalls that we think deserve more attention than they typically get. This is not a call to abandon the feature; it is a call to approach it with open eyes. The promise is that custom calendars will finally align with how your business actually operates, whether that means a fiscal year starting in July or a retail calendar built around 4-5-4 weeks. The reality, as the recent analysis on Towards Data Science makes clear, is that the flexibility can quickly turn into confusion when the underlying assumptions of the feature are not fully understood.
For practitioners, the practical takeaway is straightforward: you cannot treat calendar-based time intelligence as a drop-in replacement for the older, date-table-driven approach. When you rely on the new feature, you are implicitly trusting that the engine interprets your custom calendar exactly as you intend. That is a fragile assumption when you are dealing with irregular week numbers, leap week scenarios, or shifting year-end dates. Examples of things getting "weird" are not edge cases dreamed up by someone looking for trouble; they are the natural consequences of a system that has to make choices about how to map your custom structure onto standard time calculations. If you are not testing those choices explicitly, you will discover them later, usually when a report that worked last quarter suddenly shows a blank or a wildly off number.
The good news is that none of this requires you to abandon the feature. It does require a shift in how you validate your work. We would argue that the real skill here is not learning the feature's syntax but learning to ask better questions before you build. What happens to week-over-week comparisons when your calendar has a 53rd week? How does the engine treat a month that has only three working days because of a company holiday? These are not questions the feature will answer for you. They are questions you need to bring to the table, and then you need to verify the output against a known baseline. The feature does offer great possibilities; it is just that those possibilities are only as reliable as your understanding of the edge cases.
Our opinion is that this is exactly the kind of tension that makes working with modern data tools so rewarding and so frustrating at the same time. The feature is a genuine improvement in flexibility, but it shifts the burden of correctness onto the modeler. If you go in expecting it to just work, you will be disappointed. If you go in with a clear plan for testing, a list of your own calendar's quirks, and a willingness to compare the new results against a trusted baseline, you will find that the feature can handle a lot more than the naysayers suggest. The concrete point is this: before you roll out a custom calendar to production, build a small test file with known values for every time intelligence calculation you use. Run it through the new feature, check the numbers, and then decide if the convenience is worth the risk. That is the only way to turn a promising feature into a dependable tool.