DAX supports dates starting in 1900 and while teaching DAX I always explain that DAX manages dates like Excel, which is the reason why these limitations exist. Actually, this is true – but answering to a comment today I realized I could explain this better.
DISCLAIMER: what follows will be hardly useful in your daily job. If you continue reading this post, you will do that just for the sake of your curiosity.
DAX stores a date as a decimal number, where the integer part is the number of days elapsed since December 30, 1899 and the decimal part is the fraction of the day (6 hours = 0.25, 12 hours = 0.50, and so on).
Excel does the same, but DAX and Excel have a difference in how they represent days between December 30, 1899 and March 1, 1900.
Excel represents with 1 the day of January 1, 1900. If you try to show 0 as a date in Excel, you get the non-existing date January 0, 1900.
DAX represents with 1 the day of December 31, 1899. Why this? Because the original implementation of Lotus 1-2-3 had a bug and considered 1900 as a leap year that included February 29, 1900. Because 1900 is not a leap year, the dates before March 2, 1900 where misrepresented in Lotus 1-2-3.
In order to keep full compatibility with Lotus 1-2-3, Excel developers decided to implement the same bug in Excel – we are talking of events happened in the previous century, before Internet was a thing.
The implementation of Excel keeps the same representation used by Lotus 1-2-3 for the dates between January 1, 1900 and February 28, 1900 – which are represented by the range between 1 and 59.
The value of 60 was the non-existing day of February 29, 1900, which today is displayed in Excel as March 1, 1900. However, also 61 corresponds to March 1, 1900. Thus, both 60 and 61 are the same date in Excel: March 1, 1900.
DAX developers where not too much concerned with existing data in Excel related the first two months of 1900, so they decided for a different implementation.
DAX uses the range 1-60 for dates between December 31, 1899 and February 28, 1900. This way, March 1, 1900 has only one corresponding integer in DAX – which is 61.
The final result is that all the dates in the range 1-60 are shifted of one day between DAX and Excel. This is relevant only if you pretend to convert a number coming from Excel into a date in DAX, because if you have dates in Excel, they should be regularly converted in correct dates in DAX, even though the underlying integer number will be different.
As I said at the beginning, there is nothing really useful in knowing this, but if you ever wonder why there are these differences, now you know.
Finally, with a negative number DAX can represent dates before 1900. However, I don’t think that this is officially supported, so I would not rely on it too much.