Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Allow multiple timezones #483

Open
HaaLeo opened this issue Sep 20, 2023 · 6 comments
Open

Feature Request: Allow multiple timezones #483

HaaLeo opened this issue Sep 20, 2023 · 6 comments
Labels
triaged Has been triaged by solutions team

Comments

@HaaLeo
Copy link

HaaLeo commented Sep 20, 2023

Is your feature request related to a problem? Please describe.

We have two development teams. One sitting in Germany (timezone Europe/Berlin) and one sitting in the US (timezone US/Eastern). Both teams work from earliest 7am till latest 6pm. So the period they are working is identical. However the timezone is different.

Describe the feature you'd like

I would like Schedules to support multiple timezones. So I can link one Period (7am - 6pm) to a single schedule but apply it in multiple timezones (Europe/Berlin as well as US/Eastern)

Additional context

N/A

@CrypticCabub
Copy link
Member

Hi @HaaLeo

If I am understanding your use case correctly, Instance Scheduler should already support what you are describing.

Under the current design of Instance Scheduler, periods are timezone-agnostic and can be shared by multiple schedules. Timezones can then be defined at the schedule level with a default timezone for the entire deployment that will be used if one is not specified on the schedule itself.

To achieve the behavior you describe, you would create a period for your developer hours of 7am-6pm, and then you would create 2 schedules (developer-hours-germany and developer-hours-us). These schedules would both use the developer-hours period but would define different timezones. You can then tag your instances with whichever schedule corresponds to the timezone that they should operate under

@HaaLeo
Copy link
Author

HaaLeo commented Sep 26, 2023

Hi @CrypticCabub thx for your response. I meant it slightly different. We use a single instance for both teams. Therefore, we want either one instance Support multiple schedules or better one schedule to support multiple timezones.
I hope that makes it somewhat clear 😅.

@CrypticCabub
Copy link
Member

A single instance as in a shared EC2 instance that both teams use or a single deployment of Instance Scheduler?

If the latter, Instance Scheduler allows timezones to be defined per-schedule. The stack defines a default timezone that will be used if a schedule does not provide its own specific timezone within which it should operate. Refer to the "london-working-hours" schedule as an example in our Implementation Guide:
https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/sample-schedule.html

As for 1 schedule supporting multiple timezones, I'm not sure I understand how such a thing would be possible. How would we determine the correct state for an instance?

Suppose a schedule with a period of 14:00-16:00, and 2 timezones: UTC+5, and UTC-5. at 10:00 UTC what state is the schedule in? For one timezone it is 5:00 and for the other it is 15:00. Which time do we use to determine whether we are in our running period of 14:00-16:00?

What about a schedule with multiple periods that all define different instance_types for resizing?

The "correct" way under our current design is that each schedule defines exactly 1 timezone within which it operates (or if no timezone is provided, will fallback to the default timezone). If we need to define office hours as 9am-5pm in local time, we do so with a period, and then we can add that period to as many different schedules as we like with each schedule providing the timezone that is necessary to convert a local time into a schedulable time.

@frogamic
Copy link

frogamic commented Oct 3, 2023

@CrypticCabub I suspect I know what @HaaLeo wants, because I want the same thing, and I guess it is really a duplicate of #233

Currently I work on a project with a single Aurora cluster that services dev teams across Australia (spanning multiple timezones, with and without daylight saving). I would like to be able to shut this DB down outside working hours since it is only needed for dev environments.

Ideally, I would like to create a single schedule that specifies multiple periods in different timezones like so:

# Excerpt from schedules IaC stack
Resources:
AustralianSchedule:
  Type: 'Custom::ServiceInstanceSchedule'
  Properties:
    ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN
    Name: australian-business-hours
    Description: Cover core business hours in Australia across AWST and AEST/AEDT
    Timezone: Australia/Melbourne
    Periods:
      - Description: "8:30-5:30, mon-fri Melbourne time"
        # This one uses the schedule's default timezone of Australia/Melbourne time
        # i.e. AEST/AEDT depending on daylight saving.
        BeginTime: "08:30"
        EndTime: '17:30'
        WeekDays: 'Mon-Fri'
      - Description: "8:30-5:30, mon-fri Perth time"
        Timezone: Australia/Perth
        BeginTime: "08:30"
        EndTime: '17:30'
        WeekDays: 'Mon-Fri'

Obviously the same thing could be achieved by just specifying a single period that encompasses both the timezones, but that is less clear, more error prone and weird with daylight savings if the timezones treat it differently.

@CrypticCabub
Copy link
Member

Thanks for the clarification. I believe I've seen a similar FR before for timezone-aware periods. To say it back -- the ask is for Instance Scheduler to provide a way to specify timezones on a per-period level and allow a schedule to contain multiple of these timezone-aware periods.

I'll re-open this FR and bring it up with the team for further discussion

@CrypticCabub CrypticCabub reopened this Oct 3, 2023
@HaaLeo
Copy link
Author

HaaLeo commented Oct 3, 2023

@frogamic thx for stepping in. That's essentially what I've meant 😅. Thx for reopening @CrypticCabub 🙏🏼.

@CrypticCabub CrypticCabub added the triaged Has been triaged by solutions team label Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged Has been triaged by solutions team
Projects
None yet
Development

No branches or pull requests

3 participants