# Shifting dates to account for most recent data not being current

**URL:** <https://community.omni.co/t/shifting-dates-to-account-for-most-recent-data-not-being-current/429>\
**Category:** Patterns\
**Tags:** filtering, lod\
**Created:** [December 6, 2025, 1:18am UTC](https://community.omni.co/t/shifting-dates-to-account-for-most-recent-data-not-being-current/429 "2025-12-06T01:18:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![adrienb](https://yyz2.discourse-cdn.com/flex004/user_avatar/community.omni.co/adrienb/32/385_2.png) [@adrienb](https://community.omni.co/u/adrienb)\
**Post date:** [December 6, 2025, 1:18am UTC](https://community.omni.co/t/shifting-dates-to-account-for-most-recent-data-not-being-current/429/1 "2025-12-06T01:18:51Z")

</div>

A common data challenge involves accounting for data which may not be current, often due to a lag in upstream data pipelines. For example, you’d like to look at the past X weeks of data, but due to this lag the past X weeks is really X + Y where Y is the time since data was last updated. Here is a recorded walkthrough of one approach!

https://www.loom.com/embed/cb0f33f91d2347559a2d3775aa5d65fb

PS: If you think of other approaches please suggest them, we’d love to hear from you!