Yeah that's correct. Sorry, I should have used `pendulum.today`. But yeah
also equivalent to `pendulum.today('UTC').add(days=-N)` *(while `days_ago`
uses timedelta it's the same when there's no DST is involved)*
On Tue, Dec 28, 2021, 1:59 AM Ash Berlin-Taylor <a...@apache.org> wrote:
> 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
> <daniel.stand...@astronomer.io.INVALID> 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.
>>
>>
