[
https://issues.apache.org/jira/browse/AIRFLOW-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301046#comment-16301046
]
Bolke de Bruin commented on AIRFLOW-1930:
-----------------------------------------
It is actually a bug. The transition is handled by Airflow, all dates should be
stored in UTC regardless of what the database server thinks it is in. Note that
for many databases the current time zone is dependent on the connection (MySQL)
or connection and server setting (Postgres) or no support at all (SQLite). In
addition none of these databases are really time zone aware as they don’t store
the time zone itself. This means that transitions are not handles correctly.
This means that func.now created an arbitrary date that we cannot rely on
across workers/scheduler and it circumvented the check we do on only storing
UTC date times as it was executed at the database level. DAGs store the
information on time zones and with pendulum (and not pytz) we manage
transitions across time zones and dst.
You could argue that converting the D.B. fields to time zone aware fields was
redundant, however I think it is an improvement across the board.
> start_date and execution_date should default to timezone.utcnow() not to
> func.now()
> -----------------------------------------------------------------------------------
>
> Key: AIRFLOW-1930
> URL: https://issues.apache.org/jira/browse/AIRFLOW-1930
> Project: Apache Airflow
> Issue Type: Bug
> Affects Versions: 1.9.0, 1.8.2
> Reporter: Bolke de Bruin
> Assignee: Bolke de Bruin
> Fix For: 1.9.1
>
>
> func.now() defaults to the time zone of the database, while we assume every
> date in the db is UTC.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
