Date-related Issues (workdocs, filtering, and column format)

Platform discussions
, , , ,
1

I’m running into a few date-related limitations and inconsistencies and would appreciate clarification on whether these are expected behaviors or known gaps.

  • Workdoc widgets do not support document-level variables. As a result, dynamic filters like “Today” are always evaluated at render time instead of document creation time, making it impossible to create static, date-scoped documents such as daily meetings, reports, or snapshots. In other words, everything is live and dynamic, making processes unsuitable where time-bound accuracy matters.
    • If incorrect, please help me write a filter to achieve:
      [Date Column] is equal to [the creation date / “Today” at time of creation].
  • Additionally, exploring filters, I noticed that the date conditions “is” and “is only” appear to behave identically in practice, with no observable difference beyond “is only” exposing an “Exact date” condition (screenshot below).
  • At the board level, when a Date column has time enabled, the “Today” action updates only the calendar date and leaves the time unchanged. This behavior is unintuitive, as it’s reasonable to expect “Today” to represent the current timestamp. Is this a deliberate design choice, or a limitation of how date and time are handled internally?

Thanks

2

@al1388 welcome to the community.

There are a few practical ways to work around it, depending on the outcome you’re trying to achieve.

For Workdocs, you are correct that there are no document level variables and no concept of a frozen creation date that filters can reference. Relative values like Today, This week, etc. are always evaluated at render time. There is currently no filter you can write that means “Today at the moment this document was created.” That value is never stored anywhere for the doc, so it cannot be referenced later.

The closest workaround is to push that responsibility to the board instead of the Workdoc. A common pattern is to add a Date or Date and Time column called something like Snapshot Date or Report Date and populate it at the moment the item is created using an automation such as “When an item is created set Snapshot Date to Today” or “set Snapshot Date to Now” if you need time included. Your Workdoc widget can then filter on that stored date instead of relying on a live Today value. That gives you a stable, time scoped result even though the doc itself remains dynamic.

On the “is” versus “is only” filter behavior, you’re also observing this correctly. In practice, both behave the same for relative date options like Today, This week, and This month. “Is only” simply exposes the Exact date option for cases where you want to match one specific calendar day. There is no functional difference in how relative dates are evaluated, which is why it feels redundant. If there is an intended distinction, it isn’t currently surfaced in the UI or documentation.

For the Date column with time enabled, this is a known limitation of how monday handles date and time internally. The Date portion and the Time portion are treated as separate values. When you select Today, monday updates only the date and intentionally leaves the existing time untouched to avoid overwriting time data that may already be meaningful. While that may be deliberate, it is unintuitive for many use cases where Today is expected to mean “now.”

If you need a true current timestamp, the best option is to use an automation that explicitly sets the Date and Time to Now rather than using the Today shortcut. That is the only way to reliably capture both the current date and time in one action.

In short, these are known gaps rather than configuration mistakes. The most reliable pattern today is to store dates explicitly at creation time using automations and then filter against those stored values, instead of relying on live relative filters in Workdocs or boards.