Time Travel for Feature Flags

Sometimes a feature shouldn't be enabled now. Maybe you're launching something at noon. Maybe a promotion runs from Friday through Monday. Maybe you need a maintenance mode during a scheduled window. You could set a reminder and manually flip the flag. Or, because we're supposedly living in the future, you can let the feature flag do it for you. Enter Microsoft's Microsoft.TimeWindow filter.

The Basic Version

The TimeWindow filter enables a feature between a specified Start and End time. You can also specify just one boundary:

• Start only: enabled from that time onward.
• End only: enabled until that time.
• Start + End: enabled between those times.

Here's the basic JSON:

{
  "id": "NewFeature",
  "enabled": true,
  "conditions": {
    "client_filters": [
      {
        "name": "Microsoft.TimeWindow",
        "parameters": {
          "Start": "Tue, 15 Sep 2026 12:00:00 GMT",
          "End": "Tue, 15 Sep 2026 18:00:00 GMT"
        }
      }
    ]
  }
}

The important bit is that enabled must be true. The filter then determines whether the flag is actually enabled at evaluation time. So:

enabled = true
       +
current time is inside window
       =
FEATURE ON

Outside the window? Feature off. No deployment. No scheduled job. No developer frantically setting an alarm on their phone.

Recurring Windows

Here's where things get more interesting. The TimeWindow filter also supports recurring windows. You can define a window that repeats on a schedule, which is useful for things like enabling a feature during specific hours or days. Microsoft requires both Start and End when using recurrence; the duration between them defines the length of each recurring window.

That means you can do things like turning this feature on every weekday during business hours. Suddenly your feature flag is doing calendar math. Because apparently that's its job now.

Multiple Filters

You can also combine filters. Microsoft.FeatureManagement supports a requirement_type of All or Any. With All, every configured filter must evaluate to true. With Any, one successful filter is enough. For example, you could combine a percentage rollout with a time window:

Feature enabled
    ↓
Inside time window? ── No → OFF
    ↓ Yes
In rollout percentage? ── No → OFF
    ↓ Yes
ON

That's a surprisingly powerful amount of control for something that started life as a boolean.

One Thing to Remember

Time zones. The examples in Microsoft's documentation use explicit date/time values, including GMT/UTC offsets. Don't casually type "8:00 AM" into your configuration and assume every server, developer laptop, and container on Earth agrees about what you meant. Time is already complicated enough without adding Kubernetes.

Why Use a Time Window?

The real advantage isn't that you can schedule a feature. It's that you can separate releasing code from activating functionality. The code can be deployed ahead of time. The feature can activate automatically when you want it to, then deactivate when the window ends. That's exactly the kind of scenario feature management is designed to handle. Deploy once. Let the flag handle the clock.

Your future self has enough problems already.