The use can specify the timezone of the schedule expression in Scheduled Job

In my workload manifest.yml I have the following cron schedule:

name: morning-report
type: Scheduled Job

on:
  schedule: "cron(0 9 ? * MON-FRI *)"

But the time is assumed in UTC and the timezone can't be changed. It would be nice if the manifest could map the EventBridge scheduler option:

aws scheduler create-schedule \
  --schedule-expression "at(2022-11-20T13:00:00)" \
  --name schedule-name \
  --schedule-expression-timezone "America/Los_Angeles"

@RaffaeleSgarro

Hi @RaffaeleSgarro !

Your feature request makes sense to me, if anything Copilot could translate the schedule expression from one timezone to another.

The manifest could be something like:

on:
   schedule: "cron(0 9 ? * MON-FRI *)"
   schedule_timezone: "America/Los_Angeles"

Great! How does it work now? Do you point me to some documentation to implement it myself and send a pull request, or is it so trivial that you prefer to fix it yourself?

How does it work now? Do you point me to some documentation to implement it myself and send a pull request, or is it so trivial that you prefer to fix it yourself?

Typically, if it's going to be implemented by the AWS Copilot team we'll need to prioritize the feature request first. We update the GitHub issues saying that the team is now picking up the feature request so that users are aware of the progress.
Unfortunately, I can't make a commitment today for a timeline for the feature. However, if you'd like to send a pull-request we'd be happy to review it!

If you'd like to contribute the feature, I believe the following changes need to happen:

Adding the timezone field to the manifest file:

copilot-cli/internal/pkg/manifest/job.go

Lines 45 to 47 in 499bb1c

type JobTriggerConfig struct {

Schedule *string `yaml:"schedule"`

}

Adding validation for the new field to ensure that the string entered is a valid timezone:

copilot-cli/internal/pkg/manifest/validate.go

Lines 1550 to 1557 in 499bb1c

    
           func (c JobTriggerConfig) validate() error { 
        
           	if c.Schedule == nil { 
        
           		return &errFieldMustBeSpecified{ 
        
           			missingField: "schedule", 
        
           		} 
        
           	} 
        
           	return nil 
        
           }

Convert the cron job expression from one timezone to the next here:

copilot-cli/internal/pkg/deploy/cloudformation/stack/scheduled_job.go

Line 245 in 499bb1c

func (j *ScheduledJob) awsSchedule() (string, error) {

(although I think the last step isn't trivial)

I'd also like to see this implemented. However, just translating the expressions, before passing it to the template engine is insufficient for reoccurring jobs. The advantage of being able to select timezone is daylight savings handling.

If someone were able to rewrite the template to use AWS::Scheduler::Schedule, instead of the, currently used, AWS::Events::Rule, we'd be able to have native timezone support.

The existing template is here:

copilot-cli/internal/pkg/template/templates/workloads/partials/cf/eventrule.yml

Lines 1 to 37 in 4b8eccb

    
           Rule: 
        
             Metadata: 
        
               'aws:copilot:description': "A CloudWatch event rule to trigger the job's state machine" 
        
             Type: AWS::Events::Rule 
        
             Properties: 
        
               {{- if eq .ScheduleExpression "none"}} 
        
               ScheduleExpression: "rate(5 minutes)" 
        
               State: DISABLED  
        
               {{- else }} 
        
               ScheduleExpression: !Ref Schedule 
        
               State: ENABLED  
        
               {{- end }} 
        
               Targets: 
        
               - Arn: !Ref StateMachine 
        
                 Id: statemachine 
        
                 RoleArn: !GetAtt RuleRole.Arn 
        
           RuleRole: 
        
             Type: AWS::IAM::Role 
        
             Properties: 
        
               AssumeRolePolicyDocument: 
        
                 Version: '2012-10-17' 
        
                 Statement: 
        
                 - Effect: Allow 
        
                   Principal: 
        
                     Service: events.amazonaws.com 
        
                   Action: sts:AssumeRole 
        
               {{- if .PermissionsBoundary}} 
        
               PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/{{.PermissionsBoundary}}' 
        
               {{- end}} 
        
               Policies: 
        
               - PolicyName: EventRulePolicy 
        
                 PolicyDocument: 
        
                   Version: '2012-10-17' 
        
                   Statement: 
        
                   - Effect: Allow 
        
                     Action: states:StartExecution 
        
                     Resource: !Ref StateMachine

I ended up using the following YAML patch overrides to support my use case. May follow up with a PR to do the work described in my comment above, if there is interest. If anyone knows, if there is a way to add support for grabbing the time zone value from the manifest yaml, please let me know.

################################################################################################################
#########################################       Time zone Support      #########################################
################################################################################################################
##    Replaces AWS::Events::Rule with AWS::Scheduler::Schedule to take advtange of EventBridge Scheduler's    ##
##                                       time zone support. See TR-209                                        ##
################################################################################################################
# Update RuleRole to allow Scheduler
- op: replace
  path: /Resources/RuleRole/Properties/AssumeRolePolicyDocument/Statement/0/Principal/Service
  value: scheduler.amazonaws.com


# Use EventBridge Scheduler instead of CloudWatch Events
- op: replace
  path: /Resources/Rule/Type
  value: 'AWS::Scheduler::Schedule'

- op: add
  path: /Resources/Rule/Properties/FlexibleTimeWindow
  value:
    # Must have quotes
    Mode: "OFF"

- op: add
  path: /Resources/Rule/Properties/ScheduleExpressionTimezone
  # Set your timezone here as an IANA time zone
  value: "America/Chicago"

- op: remove
  path: /Resources/Rule/Properties/Targets
- op: add
  path: /Resources/Rule/Properties/Target
  value:
    Arn: !Ref StateMachine
    RoleArn: !GetAtt RuleRole.Arn
################################################################################################################
#########################################    End time zone Support     #########################################
################################################################################################################

Hello!!!
I am interested in this, I am trying to see if I can solve this by employing EventBridge Scheduler.

@efekarakus

Hello there

I am interested in this too.

The YAML patch is good except that CloudFormation reject resource type modification.

In next days, I will submit a pull request with

Full code coverage, from unit to integration
EventBridge Schedule that replace CloudWatch Event Rule.
UTC as default time zone
Allowing expression like 'at(2022-11-20T13:00:00)'
Resource Rule renamed to Schedule
Resource RuleRole renamed to ScheduleRole
Configurable on manifest.yml but not during job init
Reference to the documentation

# job manifest.yml

# Trigger for your task.
on:
  # The scheduled trigger for your job. You can specify a Unix cron schedule or keyword (@weekly) or a rate (@every 1h30m)
  # AWS Schedule Expressions are also accepted: https://docs.aws.amazon.com/scheduler/latest/UserGuide/schedule-types.html
  schedule: "rate(5 minutes)"

  # The timezone in which the scheduling expression is evaluated.
  # You can specify a time location like (America/New_York) or like (CET)
  # More details: https://docs.aws.amazon.com/scheduler/latest/UserGuide/schedule-types.html#time-zones
  timezone: "UTC"

cc @efekarakus

@alquerci

Thanks @alquerci! I'm looking forward to your PR. The work around for the issue you're running into is to delete/destroy the job then recreate it with the patch. The patch doesn't work on a job that's already been deployed, but once it's been deployed with the patch, it works as normal

The pull request #6011

Navigation Menu

Repository navigation

The use can specify the timezone of the schedule expression in Scheduled Job #4604

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	type JobTriggerConfig struct {
	Schedule *string `yaml:"schedule"`
	}

	func (c JobTriggerConfig) validate() error {
	if c.Schedule == nil {
	return &errFieldMustBeSpecified{
	missingField: "schedule",
	}
	}
	return nil
	}

	Rule:
	Metadata:
	'aws:copilot:description': "A CloudWatch event rule to trigger the job's state machine"
	Type: AWS::Events::Rule
	Properties:
	{{- if eq .ScheduleExpression "none"}}
	ScheduleExpression: "rate(5 minutes)"
	State: DISABLED
	{{- else }}
	ScheduleExpression: !Ref Schedule
	State: ENABLED
	{{- end }}
	Targets:
	- Arn: !Ref StateMachine
	Id: statemachine
	RoleArn: !GetAtt RuleRole.Arn
	RuleRole:
	Type: AWS::IAM::Role
	Properties:
	AssumeRolePolicyDocument:
	Version: '2012-10-17'
	Statement:
	- Effect: Allow
	Principal:
	Service: events.amazonaws.com
	Action: sts:AssumeRole
	{{- if .PermissionsBoundary}}
	PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/{{.PermissionsBoundary}}'
	{{- end}}
	Policies:
	- PolicyName: EventRulePolicy
	PolicyDocument:
	Version: '2012-10-17'
	Statement:
	- Effect: Allow
	Action: states:StartExecution
	Resource: !Ref StateMachine

The use can specify the timezone of the schedule expression in Scheduled Job #4604

Description

Activity

efekarakus commented on Mar 8, 2023

RaffaeleSgarro commented on Mar 9, 2023

efekarakus commented on Mar 9, 2023

jas32096 commented on Oct 11, 2023

jas32096 commented on Jan 30, 2024

happysiro commented on Mar 28, 2024

alquerci commented on Feb 16, 2025

jas32096 commented on Feb 17, 2025

alquerci commented on Feb 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions