days_ago is not just the same as utcnow minus N days, it is always "truncated" to the start of the day, so it's closer to "utcnow().replace(hour=0, minute=0, second=0) - timedelta(n)”
On 28 December 2021 00:08:53 GMT, Daniel Standish <[email protected]> wrote: >I recall some time ago we removed `days_ago` from all example dags. Not >sure why we didn't also deprecate it. > >For reference, `days_ago(N)` returns utcnow minus N days. > >There's a PR to make it return a value in the default timezone, so that >when you use it in an expression for dag `start_date`, the dag will be in >the default timezone. > >I don't want to get into the merits of that here. But even assuming that >this would be desirable, there's still some ambiguity we'd have to >resolve. Namely, should we return `now minus N 24-hour periods` (as `now - >timedelta(N)` would do) or should we return now minus N days (as >pendulum.now().add(days=-N) would do)? Because of DST the two >different approaches result in values that differ by 1 hour. > >What I *do* want to explore here is whether folks think we can / should >just deprecate the function entirely. Personally this would be my >preference. Using `days_ago(5)` is not much more convenient than >`dttm.add(days=-N)`. And the latter has the benefit that it is >unambiguous, doesn't make assumptions, and doesn't get in the way between >user and library. > >So my proposal would be, don't change the behavior of `days_ago` and >deprecate it with removal targeted in 3.0.
