Re: execution_date - can we stop the confusion?

Changing terms or aliasing may both introduce another set of confusions. Refining the documentation systematically may be a more feasible solution to this sort of issues? Like having “execution_date” in “Concepts” section, or having a dedicated section named “Vocabularies” to list all potentially

Re: execution_date - can we stop the confusion?

I'm not against aliasing personally. The downside is that it creates more vocabulary overall and most users will need to learn the mapping of the given aliases at some point in their learning curve anyways. Only users in environments free of `execution_date` will benefit from less confusion, and

Re: execution_date - can we stop the confusion?

Yep. Aliasing seems a reasonable solution that preserve the structure and make things simpler for new users. While I agree with everyone that learning a new technology has learning curve still we can see more and more theologies embrace the user friendly flag. Sent with ProtonMail Secure

Re: execution_date - can we stop the confusion?

port> [1500660332982_2017] From: a...@apache.org Sent: Friday, September 28, 2018 11:47:16 PM To: dev@airflow.incubator.apache.org Subject: Re: execution_date - can we stop the confusion? What about (aliasing) execution_date to period_start, and next_execution_date to

Re: execution_date - can we stop the confusion?

What about (aliasing) execution_date to period_start, and next_execution_date to period_end? Would this help any do we think? (Though things like ds and ts might still be confusing? This is probably where the OP got the idea for run_stamped from? One step at a time.) Ash On 27 September 2018

Re: execution_date - can we stop the confusion?

I would like to challenge the notion that "execution_date" is well documented. Looking at airflow.apache.org right now and searching for all references to "execution_date", I find that the only definition of execution_date is, "The execution date of the DAG". There are some other passing

Re: execution_date - can we stop the confusion?

Second use of “inane” on this subject. Brilliant, less combative response Chris. There’s another point.. left bound makes sense to some people, right bound to others. There’s no way to know or measure how “hard” this is to new users, so even if the change was made - new name, use right

Re: execution_date - can we stop the confusion?

While taking a step back makes some sense, we also need to identify what the issue is. Simply saying 'execution_date behavior is confusing to new users' isn't good enough. What is confusing about it? Is it what it represents, or just the name itself? There are a number of different timestamps

Re: execution_date - can we stop the confusion?

This comes up a lot. I've seen it on this mailing list multiple times and it's something that I have to explicitly call out to every single person that I've helped train up on Airflow. If we take a moment to set aside why things are the way they are, what the documentation says, and how

Re: execution_date - can we stop the confusion?

It took a minute to grok, but in the larger context of how af works it makes perfect sense the way it is. Changing something so fundamentally breaking to every dag in existence should bring a comparable benefit. Beyond the avoiding teaching a concept you disagree with, what benefits does the

Re: execution_date - can we stop the confusion?

This has been clearly documented as Bolke stated. It is an integral part of Airflow and a user learning Airflow needs to learn this. If you think it in an ETL perspective it completely makes sense. Also, if you can use you real name than "airflowuser" would be good, your preference though. Also,

Re: execution_date - can we stop the confusion?

I think if you have a functional mindset (as in "functional data engineering ") as opposed to a cron mindset, using the left bound of the time interval makes a lot of sense.

Re: execution_date - can we stop the confusion?

Hi Bolke Speaking as a consultant who is constantly training other teams how to use airflow, I do frequently see this confusion. Another one is how the batch_date is always batch_date + interval or as the docs make it quite clear "*Let’s Repeat That* The scheduler runs your job one

Re: execution_date - can we stop the confusion?

I dont think this makes sense and I dont that think anyone had a real issue with this. Execution date has been clearly documented and is part of the core principles of airflow. Renaming will create more confusion. Please note that I do think that as an anonymous user you cannot speak for any

execution_date - can we stop the confusion?

One of the most annoying, hard to understand and against all common sense is the execution_date behavior. I assume that any new Airflow user has been struggling with it. The amount of questions with answers referring to : https://airflow.apache.org/scheduler.html?scheduling-triggers is