The reason is that DAX needs the values of an actual date column to work its magic. How will it be able to go back one year if it has a int value? If you don’t use the ALL in your example the row context that is being created by the relationship will only return a single row from the date table. And it needs all rows from the date column to be able to use the time intel function (hence the ALL).

Hope that answers your question.
Kasper

Thanks,
Hans.

Indeed, after some practice I found out that date and time function work much better joining them on a date field. Processing time is also much shorter.

Thanks again, Frits
Building datawarehouses on SAP without SAP BW

Clear. Indeed these are golden rules. After creating the join between the time table and the fact table on a date field, functions with YTD and filters on date are doing what you expected without building workarounds. Also the processing time takes much, much shorter.

Thanks again,
Frits
http://www.newfrontiers.com

For a multiple reason, check out this blog post for an example:
http://www.powerpivotblog.nl/ok-why-should-i-want-to-load-an-entire-time-table-in-powerpivot
and
http://www.powerpivotblog.nl/powerpivot-time-intelligent-functions-revisited-why-use-all-and-how-to-work-around-it

Kasper

Thanks a lot for this. In our dataset (it is a datawarehouse on SAP R/3 data) in de DWH area we work with artificial keys. Also for the time table. So far I did not encounter problems with these, but I’m relative new to DAX. What kind of problems, or functions not properly working can I expect?

Groet, Frits
Building datawarehouses on SAP without SAP BW