fix: set default timezone to UTC for cron timezone conversions

[danielli-ziprecruiter]

SUMMARY

This fix addresses the issue mentioned in #29797. The datetime object passed into the cron scheduling function may not have a timezone associated with it. Therefore, when trying to convert the datetime to the specified timezone, it just adds timezone to the datetime. This is an issue because the function attempts to convert the datetime back into UTC, which causes an incorrect timezone conversion in this case. The fix is to add UTC to the timezone info for the datetime object before converting it to the specified timezone.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

Attempt to reproduce the bug as described in #29797. The alert should trigger correctly.

ADDITIONAL INFORMATION

• [ x] Has associated issue: Reporting / Alert scheduling doesn't properly convert timezones #29797
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.72%. Comparing base (76d897e) to head (0b9a4f5).
Report is 523 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #29798       +/-   ##
===========================================
+ Coverage   60.48%   83.72%   +23.23%     
===========================================
  Files        1931      527     -1404     
  Lines       76236    38006    -38230     
  Branches     8568        0     -8568     
===========================================
- Hits        46114    31819    -14295     
+ Misses      28017     6187    -21830     
+ Partials     2105        0     -2105     

Flag	Coverage Δ
hive	49.05% <100.00%> (-0.11%)	⬇️
javascript	?
mysql	76.83% <100.00%> (?)
postgres	76.90% <100.00%> (?)
presto	53.60% <100.00%> (-0.20%)	⬇️
python	83.72% <100.00%> (+20.23%)	⬆️
sqlite	76.39% <100.00%> (?)
unit	59.96% <0.00%> (+2.33%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mistercrunch]

I haven't dug in the code, but will this cause a change in behavior (meaning the actual time at which certain alerts will trigger) in some environments for some alerts? If that's the case we should either prevent that with some flag and/or adding a comment in UPDATING.md to let administrator know what might be affected and how to tweak things to preserve the current timing/behavior.

[eschutho]

Thanks @danielli-ziprecruiter for the PR! In addition to @mistercrunch's comments, can you add some tests to this PR?

[danielli-ziprecruiter]

Yes, this would cause a change in behavior, but the previous behavior didn't make sense since the alert / reporting run would not occur at the configured time and timezone and instead occur at time offset by the configured timezone's relation to UTC. I can still add a comment in UPDATING.md calling this out though.

[mistercrunch]

he alert / reporting run would not occur at the configured time and timezone and instead occur at time offset by the configured timezone's

Makes sense, though wondering its possible that people might have set their alerts/reports while relying on this quirky behavior.

Can we clarify the scope of alerts that would be affected (say "only the ones that set a TZ")? Is this an edge case or does it affect most alerts out there? We have to think of the thousands of organizations running hundreds of thousands or alerts/reports every day...

If it's a small portion of alerts/reports, maybe a note in UPDATING.md is sufficiant.

If it's a a large portion of alerts/reports, we have different options

• a db migration that makes sure that effective run time of alerts are not affected, altering the existing alerts
• wait for the next major release to ship as a breaking change
• some sort of flag for each alert (new_scheduling_logic = True/False) where we apply the old/new logic conditionally

[danielli-ziprecruiter]

I think I've found where this issue was actually introduced. This commit changes datetime.now(tz=dt_timezone.utc) to datetime.utcnow(). datetime.utcnow() is not timezone aware, hence the issue described earlier. I've updated the PR accordingly. Would I still need to add additional tests or comments to UPDATING.md?

[mistercrunch]

I think a message in https://github.com/apache/superset/blob/master/UPDATING.md seems important to let people know about any "change in behavior" for when they are upgrading. In theory whoever conducts upgrades should read through that file and ack the notices, notify their users, or take action if needed. Ideally the message is clear about the scope of the change of behavior (which types of alerts/reports will be affected, maybe it's only the alerts/reports that specify a TZ, idk) and what's the old/new behavior.

[mistercrunch]

@michael-s-molina @rusackas did we not think a comment in UPDATING.md was helpful/necessary?

[michael-s-molina]

I'm sorry @mistercrunch, I think I missed your comment. I agree that a comment in UPDATING.md is necessary. @danielli-ziprecruiter could you open a follow-up please?

[mistercrunch]

I just created a new hold:updating.md label we can use in the future that should prevent merging without having to do a "requires changes" review