uranusjr commented on a change in pull request #16678:
URL: https://github.com/apache/airflow/pull/16678#discussion_r659895589
##########
File path: airflow/models/dag.py
##########
@@ -302,16 +304,20 @@ def __init__(
self.fileloc = back.f_code.co_filename if back else ""
self.task_dict: Dict[str, BaseOperator] = {}
- # set timezone from start_date
+ # set timezone from schedule_timezone or start_date
+ if schedule_timezone:
+ self.schedule_timezone =
self._get_tzname_or_offset(schedule_timezone)
Review comment:
> There is no problem to specify the `start_date` in one timezone, the
`end_date` in another timezone, and have yet another timezone for the
`schedule_timezone`. I can see people (myself included) using iso 8601 string
like `2021-06-01T12:00:00+01:00` for `start_date` and
`schedule_timezone='Europe/Stockholm'`
Hmm, that makes sense. And since if `schedule_timezone` is _not_ set,
`start_date.tzinfo` will be used anyway, there is no behavioural change for
people not (yet) modifying their DAGs. And when `schedule_timezone` is set, the
user should know what they’re doing.
> But anyway, I'm removing `schedule_timezone` from the PR, right? Because
that changes the public api of the DAG and that requires an AIP, right?
I think so, yes, but we’re going to need to have this discussion when
explicit per-DAG timezone setup becomes a thing (whether via
`schedule_timezone` or another mean) anyway.
--
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]
