Skip to content

Conversation

fossamagna
Copy link
Contributor

@fossamagna fossamagna commented Oct 6, 2025

Problem

Function schedules are powered by Amazon EventBridge rules, so not supported timezone.
Migrate EventBridge Scheduler to support timezone.

Issue number, if available:

fix #3008

Changes

Added a function schedule format that specifies the timezone.
We migrated from EventBridge rules to EventBridge Scheduler to support time zones.

Corresponding docs PR, if applicable:

aws-amplify/docs#8448

Validation

Checklist

  • If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
  • If this PR requires a change to the Project Architecture README, I have included that update in this PR.
  • If this PR requires a docs update, I have linked to that docs PR above.
  • If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link

changeset-bot bot commented Oct 6, 2025

🦋 Changeset detected

Latest commit: 2debf5a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@aws-amplify/backend-function Minor
@aws-amplify/backend Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@fossamagna fossamagna marked this pull request as ready for review October 6, 2025 15:00
@fossamagna fossamagna requested review from a team as code owners October 6, 2025 15:00
Copy link
Contributor

@iankhou iankhou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, added some comments.

} else if ('cron' in schedule) {
return { ...schedule, timezone: schedule.timezone ?? DEFAULT_TIMEZONE };
}
throw new Error("Could not determine the function's schedule type");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Error is not tested, can you include a test that covers it?

});
});

void it('sets valid schedule - rate with timezone', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add some test cases for invalid inputs for rate and timezone (invalid timezone)?

@iankhou
Copy link
Contributor

iankhou commented Oct 7, 2025

One of our workflows is failing because the changeset bumps @aws-amplify/backend-function but not @aws-amplify/backend. It needs to bump both, as @aws-amplify/backend-function can't be higher than @aws-amplify/backend.

@@ -0,0 +1,5 @@
---
'@aws-amplify/backend-function': minor
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to bump @aws-amplify/backend too.

@fossamagna
Copy link
Contributor Author

@iankhou
Thank you for your review.
I have addressed the comments you suggested.

Copy link
Contributor

@iankhou iankhou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing, we should use TimeZone instead of string timezones, unless there is a very good reason not to.

CronOptionsWithTimezone,
ScheduleExpression,
} from 'aws-cdk-lib/aws-scheduler';
import { TimeZone } from 'aws-cdk-lib';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see we are importing TimeZone here, why do we use string timezones in the rest of the changes?

return { minute: `*/${value}` };
return {
minute: `*/${value}`,
timeZone: TimeZone.of(schedule.timezone),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not pass a TimeZone directly instead of making this conversion?

Comment on lines +155 to +161
timezone: string;
};

// @public (undocumented)
export type ZonedTimeInterval = {
rate: TimeIntervalExpression;
timezone: string;
Copy link
Contributor

@iankhou iankhou Oct 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as comments above - TimeZone

@iankhou iankhou added the feature-request New feature or request label Oct 8, 2025
@fossamagna
Copy link
Contributor Author

@iankhou
I noticed that none of the properties in FunctionProps use CDK types, so I assumed this was an intentional design choice.
Following this pattern, I chose to use the string type for FunctionSchedule.timezone instead of the CDK TimeZone.
If my assumption is incorrect, please let me know. I'd be happy to change it back to use the CDK TimeZone type.

@iankhou
Copy link
Contributor

iankhou commented Oct 9, 2025

Not sure if that is intentional. I will consult with the team and get back to you soon.

Some additional info -

Did some research on this implementation and came away with the following findings:

Case 1: Your approach of:

timeZone: TimeZone.of(schedule.timezone),

fails an SDK call at deploy time when the timezone is invalid - which is good.

Case 2: An alternate approach of:

timeZone: schedule.timezone as unknown as TimeZone,

does not fail deployment, and defaults to UTC

I had been worried that your implementation may fall victim to Case 2, but it does not.

Still, would be best if we catch problems with the timezone at compile time.

Copy link
Contributor

@iankhou iankhou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we do have the precedence of using strings for these props.

Using strings instead of CDK types here makes configuration easier in some cases. I will approve this PR as-is.

Thanks @ShadowCat567 for confirming this, and thank you for your patience!

@iankhou iankhou merged commit 603e831 into aws-amplify:main Oct 9, 2025
52 checks passed
@fossamagna
Copy link
Contributor Author

@iankhou Thank you for your prompt and polite response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature-request New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add support Timezone to Scheduling Lambda functions

3 participants