What library or code are you using to do the conversion between your Eastern timestamp and generate the cron expression? I think answering this part of your question is dependent on that information.
Anyway, this idea kind of sounds like a code smell to me. While it would technically work, assuming you library supports that use case correctly and that the timezone library is kept up-to-date, I believe you're better off going with the standard route of determining the crontab schedule you want upfront and using that consistently.
It's also a best practice to not use local time zone, for example, in the case where you move your server from Eastern to Pacific or operate multiple servers in different timezones — using UTC everywhere keeps it simple as you scale up.
Since UTC does not have daylight saving time, this will help you avoid things like DST bugs that you'd otherwise have to address if not using UTC.
Additionally, the official Airflow docs recommend against using naive datetimes:
Because Airflow uses time-zone-aware datetime objects. If your code creates datetime objects they need to be aware too.
...
Although Airflow operates fully time zone aware, it still accepts naive date time objects for start_dates and end_dates in your DAG definitions. This is mostly in order to preserve backwards compatibility.
...
Unfortunately, during DST transitions, some datetimes don’t exist or are ambiguous. In such situations, pendulum raises an exception. That’s why you should always create aware datetime objects when time zone support is enabled.
https://github.com/apache/incubator-airflow/blob/master/docs/timezone.rst
Can you elaborate on your use case for using naive datetimes vs timezone aware datetimes? I'd be happy to add more specific advice about that.
