Native server-side CURRENT_DATE() (or TM1System.CurrentDate) in TM1 MDX for dynamic, time-relative subsets

Dear team, 

Problem Statement

IBM Planning Analytics relies heavily on MDX to define dynamic subsets in dimensions—especially time/date dimensions—used across:

• Planning Analytics Workspace (PAW) explorations and books
• Reporting views and automated server-side processes
• Self-service, date-relative analysis

However, pure MDX currently provides no native, server-side mechanism to access the current server date or time (equivalent to TODAY() / NOW() in Rules or TI).

As a result, modelers must rely on persistent workarounds, each with significant drawbacks:

• Dedicated control/parameter cubes populated via daily TI chores or rules
• Client-side injection via Excel / PAfE / PAW parameters (not usable in TI, APIs, Perspectives, or pure server-side MDX)
• Hard-coded dates or periodic manual subset updates

These approaches increase model complexity, introduce maintenance overhead, create hidden dependencies, and reduce self-service cleanliness.
This limitation has been a well-known and long-standing pain point in the TM1 community since approximately 2009.

Business Value / Use Cases

Providing a native, server-side date/time reference in MDX would immediately enable:

• Dynamic “today”, “current period”, “open items”, or “actuals-to-date” views in finance, operations, and logistics cubes
• True rolling forecasts (YTD/QTD, rolling 3/6/12 months) without daily TI orchestration
• Self-updating PAW books and explorations for current week/month/quarter that remain correct across weekends, holidays, and server events
• Elimination of one or more control cubes and their associated chores/rules per time-dependent model
• Significantly reduced long-term maintenance effort and lower risk of stale or inconsistent date logic

This directly supports self-service modeling goals while preserving TM1’s deterministic, server-centric architecture.

Proposed Solution

Option A: Native MDX Function (preferred for flexibility)

Introduce one or more TM1-specific MDX functions, analogous to existing extensions such as TM1FILTERBYLEVEL or TM1SUBSETALL:

1. CURRENT_DATE([format])

• Returns current server date as a string
• Default format: "YYYY-MM-DD"
• Optional formats: "YYYYMMDD", "YYYY-MM", etc.
• Optional day offset (positive or negative) for simple date arithmetic
  e.g. current date − 1 day, current date + N days

1. CURRENT_DATETIME() (optional)

• Returns current server date and time

Option B: Read-only System Context Property (alternative / fallback)

Expose a server-side system context object to MDX, for example:

• TM1System.CurrentDate
• TM1System.CurrentMonth
• TM1System.CurrentYear

(returned as strings or member-compatible values)

Example Usage

Filter to current date:

FILTER(  TM1FILTERBYLEVEL( TM1SUBSETALL([Date]), 0 ),  [Date].CurrentMember.Name = CURRENT_DATE() )

Yesterday (T-1) with explicit formatting:

FILTER(  TM1FILTERBYLEVEL( TM1SUBSETALL([Date]), 0 ),  [Date].CurrentMember.Name = CURRENT_DATE("YYYY-MM-DD", -1) )

Rolling periods (e.g. from current month):

FILTER(  TM1FILTERBYLEVEL( TM1SUBSETALL([Date]), 0 ),  [Date].CurrentMember.Name >= CURRENT_DATE("YYYY-MM") )

Pattern-based filtering (elements starting with today):

TM1FILTERBYPATTERN(  TM1FILTERBYLEVEL( TM1SUBSETALL([Date]), 0 ),  CURRENT_DATE() & "*" )

Design Considerations (Alignment with TM1 Engine Principles)

To preserve TM1’s deterministic, cache-aware execution model, the following constraints are explicitly acceptable:

• Evaluated once per MDX execution context, not per cell or row
• Uses server time only (no client or user timezone dependency)
• Read-only; not writable and not usable inside Rules
• Safe for caching, parallel execution, and view materialization
• No automatic intra-day recalculation; results remain stable until MDX is re-evaluated

These constraints ensure predictable, high-performance behavior fully consistent with TM1’s core design philosophy.

Priority

High — this affects nearly every time-based planning, forecasting, actuals, and operational model using dynamic MDX subsets.
The feature would reduce model footprint, improve maintainability, and address a long-standing limitation for a large portion of real-world Planning Analytics implementations.

With best regards, 
Vitalij