Xilorole opened a new issue #17720:
URL: https://github.com/apache/airflow/issues/17720
<!--
Welcome to Apache Airflow!
Please complete the next sections or the issue will be closed.
-->
**Apache Airflow version**: 2.1.1
<!-- AIRFLOW VERSION IS MANDATORY -->
**OS**:Chromium OS 11.0 ( on google cloud composer)
<!-- MANDATORY! You can get it via `cat /etc/oss-release` for example -->
**Apache Airflow Provider versions**:
<!-- You can use `pip freeze | grep apache-airflow-providers` (you can leave
only relevant ones)-->
**Deployment**: None
<!-- e.g. Virtualenv / VM / Docker-compose / K8S / Helm Chart / Managed
Airflow Service -->
<!-- Please include your deployment tools and versions: docker-compose, k8s,
helm, etc -->
**What happened**:
The parameter `schedule_interval` when instantiating the `DAG` object does
not respect the `default_timezone` set by airflow.cfg when using
`airflow.utils.dates.days_ago` as `start_date`.
I am setting the default timezone to Asia/Tokyo. When I use the start_date,
the schedule_interval respects the default timezone, but by using the days_ago,
the schedule are set on UTC.
<!-- Please include exact error messages if you can -->
**What you expected to happen**:
The scheduled runtime is to be set with respect to the default timezone.
<!-- What do you think went wrong? -->
**How to reproduce it**:
add the below to airflow.cfg
```
default_timezone = Asia/Tokyo
```
run
```python
from airflow import DAG
from airflow.utils.dates import days_ago
from airflow.operators import dummy_operator
with DAG(
"test",
schedule_interval = "0 10 * * *",
start_date = days_ago(1)
) as dag:
t_start = dummy_operator.DummyOperator(task_id="start")
t_end = dummy_operator.DummyOperator(task_id="end")
t_start >> t_end
```
<!--
As minimally and precisely as possible. Keep in mind we do not have access
to your cluster or dags.
If this is a UI bug, please provide a screenshot of the bug or a link to a
youtube video of the bug in action
You can include images/screen-casts etc. by drag-dropping the image here.
-->
**Anything else we need to know**:
After a couple of inspections, I found that using `utcnow()` in the
`days_ago` function, which drop timezone info was the reason why it didn't
respect the timezone.
https://github.com/apache/airflow/blob/4da4c186ecdcdae308fe8b4a7994c21faf42bc96/airflow/utils/dates.py#L255-L261
Defining a function that respect the timezone fixed this issue.
```python
def days_ago(n, hour=0, minute=0, second=0, microsecond=0):
import pendulum
import os
import datetime as dt
from datetime import timedelta
tz =
pendulum.tz.timezone(os.environ.get("AIRFLOW__AIRFLOW__CORE__DEFAULT_TIMEZONE"))
today = dt.datetime.now(tz=tz).replace(hour=hour, minute=minute,
second=second, microsecond=microsecond)
return today - timedelta(days=n)
```
<!--
How often does this problem occur? Once? Every time etc?
Any relevant logs to include? Put them here inside fenced
``` ``` blocks or inside a foldable details tag if it's long:
<details><summary>x.log</summary> lots of stuff </details>
-->
**Are you willing to submit a PR?**
If this is not what it was intended to happen, of course!
<!---
This is absolutely not required, but we are happy to guide you in the
contribution process
especially if you already have a good understanding of how to implement the
fix.
Airflow is a community-managed project, and we love to bring new
contributors in.
Find us in #airflow-how-to-pr on Slack!
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
