The error "Expression.Error: The name 'DateTime.LocalNow' wasn't recognized" occurs in Power Query when the M-code interpreter cannot identify the requested function name. This error is almost always caused by a casing typo (such as writing Datetime.LocalNow or datetime.localnow), missing invocation parentheses (), or wrapping the function name inside text quotation marks. In the Power Query M language, all function names are strictly case-sensitive.
Fast Fix
Power Query M is strictly case-sensitive. The function must be spelled exactly as
DateTime.LocalNow(), with capital letters for D, T, L, and N, followed by open and closed parentheses(). Correct any variations such asDatetime.LocalNow()orDateTime.localnow(), and ensure the function is not enclosed in quotation marks.
Diagnostic Snapshot
| Property | Details |
|---|---|
| Error Type | Expression.Error |
| Exact Message | The name 'DateTime.LocalNow' wasn't recognized. Make sure it's spelled correctly. |
| Core Reason | M language strict case sensitivity or invalid syntax |
| Correct Syntax | DateTime.LocalNow() |
| Return Type | datetime (e.g., 2026-09-14 17:00:00) |
Why Power Query Fails to Recognize the Name
Unlike Excel worksheet formulas (which automatically correct sum to SUM and ignore casing), the Power Query M language treats uppercase and lowercase characters as completely different identifiers:
DateTime.LocalNow() ──► VALID: Built-in library function
Datetime.LocalNow() ──► UNRECOGNIZED: Engine searches for an unknown variable
datetime.localnow() ──► UNRECOGNIZED: Engine searches for an unknown variable
When you type Datetime.LocalNow(), the M compiler does not interpret it as a misspelled system function. Instead, it assumes you are referencing a custom variable or query step named Datetime.LocalNow. When it searches the current query scope and finds no step with that exact name, it halts evaluation with: The name ‘…’ wasn’t recognized.
Common Syntax Errors and Corrections
1. Incorrect Letter Casing
The most frequent mistake is lowercase letters in the module prefix (DateTime) or function suffix (LocalNow).
- Incorrect:
= Datetime.LocalNow() - Incorrect:
= DateTime.localNow() - Incorrect:
= datetime.localnow() - Correct:
= DateTime.LocalNow()
2. Missing Invocation Parentheses ()
In M-code, writing a function name without parentheses refers to the function definition itself as an object, rather than executing it. If used inside an arithmetic or comparison expression, it fails:
- Incorrect:
= DateTime.LocalNow - Correct:
= DateTime.LocalNow()
3. Enclosing the Function in Text Quotes
When adding a custom column through the user interface, wrapping the function in double quotes causes Power Query to treat it as a literal string rather than an executable command:
- Incorrect:
[Column = "DateTime.LocalNow()"](Outputs the literal text “DateTime.LocalNow()”) - Correct:
[Column = DateTime.LocalNow()](Outputs the current timestamp)
Practical Implementation Patterns
Pattern A: Adding a “Last Refreshed” Timestamp Column
To add a column showing the exact date and time the data was pulled:
- In the Power Query Editor, go to the Add Column tab and click Custom Column.
- Name the column
RefreshTimestamp. - In the formula box, enter:
DateTime.LocalNow() - Click OK.
- Set the new column’s data type to Date/Time by clicking the icon in the column header.
Add Custom Column:
Column Name: RefreshTimestamp
Formula: = DateTime.LocalNow()
Pattern B: Extracting Only the Current Date
DateTime.LocalNow() returns both the date and the time. If you only need today’s date for filtering or comparisons, wrap the function inside DateTime.Date():
// Returns only the current calendar date (e.g., 2026-09-14):
CurrentDate = DateTime.Date(DateTime.LocalNow())
Pattern C: Dynamic Date Filtering (e.g., Records from the Last 30 Days)
To filter rows relative to the current date:
let
Source = Sql.Database("server", "db"),
Data = Source{[Schema="dbo",Item="Orders"]}[Data],
// Calculate cutoff date safely:
CutoffDate = Date.AddDays(DateTime.Date(DateTime.LocalNow()), -30),
// Filter rows using the dynamic variable:
FilteredRows = Table.SelectRows(Data, each [OrderDate] >= CutoffDate)
in
FilteredRows
Pattern D: Cloud Consistency (UTC vs. Local Time)
DateTime.LocalNow() reads the system clock of the machine running the query.
- If you refresh the workbook on your local laptop, it uses your local time zone.
- If the workbook is refreshed by a cloud service (such as Power BI Service or Excel for the Web), it will evaluate using the cloud container’s system clock (which is always UTC).
To prevent time zone shifts when moving workbooks between local PCs and the cloud, use DateTimeZone.UtcNow() instead:
// Safe for both desktop and cloud scheduled refreshes:
CurrentUtcTime = DateTimeZone.UtcNow()
If your query encounters parsing errors when handling date text strings, see “DataFormat.Error: We couldn’t parse the input provided as a Date”. If variable references in custom M scripts break after renaming steps, refer to How to Fix “Step references an unknown variable” in M-Code]. If key lookups fail during navigation, consult “Expression.Error: The key didn’t match any rows in the table”]. If your system clock drifts and causes Microsoft 365 authentication failures, see How to Fix “The clock on your computer is incorrect” Activation Bug.