Currently, when specifying a cron expression in a model, it is always applied in the UTC timezone. However, sometimes it is important to run models at a specific time in a specific timezone.
This proposal suggests introducing a new attribute to the model definition (e.g., cron_tz), which specifies the timezone SQLMesh should use when computing the next timestamp for the model's execution.
Please note, that supporting custom timezones for data intervals and start_* / end_* macros is out of scope of this proposal. The impact of this is strictly limited to the cron expression.
Model definition example:
MODEL (
name test_schema.test_model,
cron '0 1 * * *',
cron_tz ' EST',
);
When computing the next execution timestamp, SQLMesh should first apply the custom timezone to the input timestamp serving as the basis for the calculation, determine the next timestamp, and then convert the result back to UTC before returning it for further processing.
The new cron_tz attribute should also be available as part of the model defaults configuration.
Currently, when specifying a cron expression in a model, it is always applied in the UTC timezone. However, sometimes it is important to run models at a specific time in a specific timezone.
This proposal suggests introducing a new attribute to the model definition (e.g.,
cron_tz), which specifies the timezone SQLMesh should use when computing the next timestamp for the model's execution.Please note, that supporting custom timezones for data intervals and
start_*/end_*macros is out of scope of this proposal. The impact of this is strictly limited to thecronexpression.Model definition example:
When computing the next execution timestamp, SQLMesh should first apply the custom timezone to the input timestamp serving as the basis for the calculation, determine the next timestamp, and then convert the result back to UTC before returning it for further processing.
The new
cron_tzattribute should also be available as part of the model defaults configuration.