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.
