If you used the DATESYTD and TOTALYTD functions in DAX, you might have noticed that the optional parameter year_end_date is a string defining the last day of the year. The default is December 31, so this parameter is used only when the end of the fiscal year does not correspond to December 31.
For example, you can write a formula for the YTD calculation of a fiscal year starting on June 30th this way:
Sales YTD := CALCULATE ( [Sales], DATESYTD ( 'Date'[Date], "06/30" ) -- MM/DD format )
Well, you might use this other version:
Sales YTD := CALCULATE ( [Sales], DATESYTD ( 'Date'[Date], "30/06" ) -- DD/MM format )
Depending on the locale settings you might have MM/DD or DD/MM format. In the past, DAX wanted the correct locale or it would have raised an error in case the date was not a valid one. However, current version of Power BI accepts both versions, regardless of the locale settings.
Usually you have the end of the fiscal year corresponding to the end of a month, which is not an issue. But why we are using either DD/MM or MM/DD formats, which are ambiguous for dates in the first 12 days of a month? Basically, because of this sentence in the documentation:
The year_end_date parameter is a string literal of a date, in the same locale as the locale of the client where the workbook was created. The year portion of the date is not required and is ignored.
Luckily, we have a better geeky way to express a date: use YYYY-MM-DD! The DATESYTD and TOTALYTD functions will ignore the year, but there will be no ambiguity about day and month.
Sales YTD := CALCULATE ( [Sales], DATESYTD ( 'Date'[Date], "2018-06-30" ) -- YYYY-MM-DD format )
It’s a small thing, but it is consideration that is valid whenever a literal can be converted to a date in DAX.
If you have to write that string, use the YYYY-MM-DD format and avoid locale settings issues at all.
UPDATE 2018-04-20: in case you want to mark end of February, it is a good idea to provide the last day of a leap year, such as 2020-02-29. This way, you will always include the last day of February, also for leap years.
UPDATE 2018-05-22: there is a bug managing leap years in YTD function, workaround described in a new blog post.