[
https://issues.apache.org/jira/browse/AIRFLOW-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302287#comment-16302287
]
Bolke de Bruin commented on AIRFLOW-1930:
-----------------------------------------
No apology required, it’s good to have a content discussion.
I’m not convinced that we should move to calculating the UTC datetime on the
server for three main reasons:
1. Maintainability. The cross dialect version, will require us to maintain a
sql version of UTC for every database dialect that we support. We support
currently 3 databases, but people also run airflow with MSSql and Oracle. This
means 3+2 databases all with their own quirks.
2. DB configuration dependency. In the example of your configuration for Oracle
and Postgres it makes us dependent on value the timezone has been set in the
config of those databases or the connection setting. This could be documented
of course, but airflow is notoriously lacking in that space :-) and it makes
the out of the box experience a little less dependable.
3. I have yet to see a case within airflow where it would really have added
value. If you need to set a consistent datetime across multiple rows or in a
batch make sure to set it in code. Speed is also not improved: to obtain the
value of the created / updated row it requires another round trip to the
database, while the value would otherwise be readily available.
Lastly, what would we do with all the other places where we use
timezone.utcnow()? Some can be replaces by sql_utcnow but others cannot. It
just gets a bit complex in my opinion.
> 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)
