“Expression.Error: The name ‘DateTime.LocalNow’ wasn’t recognized” (Syntax Fix)

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 as Datetime.LocalNow() or DateTime.localnow(), and ensure the function is not enclosed in quotation marks.


Diagnostic Snapshot

PropertyDetails
Error TypeExpression.Error
Exact MessageThe name 'DateTime.LocalNow' wasn't recognized. Make sure it's spelled correctly.
Core ReasonM language strict case sensitivity or invalid syntax
Correct SyntaxDateTime.LocalNow()
Return Typedatetime (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:

  1. In the Power Query Editor, go to the Add Column tab and click Custom Column.
  2. Name the column RefreshTimestamp.
  3. In the formula box, enter: DateTime.LocalNow()
  4. Click OK.
  5. 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.