Feature request: Time based feature flags actions

[ran-isenberg]

Use case

I've got a few use cases for feature flags rule actions. It's possible to due that today but its really finicky.

1. I'd like to turn on/enable a feature flags rule only during a certain time of the day (between 10:00-23:00 24 hours clock)
2. i'd like to turn on/enable a feature flags rule during a certain date range (UTC time)
3. i'd like to turn on/enable a feature flags rule only during weekends, or just weekdays
4. i'd like to turn on/enable a feature flags rule during certain week days and certain hours

I'd like to be able to do combine these conditions with other conditions.

I think the implementation is simple, just need to define the UX.

Solution/User Experience

Time based conditions are sorely missing from the current solution.

Alternative solutions

use regular actions. Use rules that define time as unix time ints and define actions like KEY_GREATER_THAN_VALUE and KEY_LESS_THAN_VALUE.
Not really readable when using unix time ints but it can work.
Not agreat UX.

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[ran-isenberg]

@heitorlessa I think I can create a PR if we agree about necessity/basic user experience, i.e how the rule will look like in the JSON. The actions and their tests should be simple enough to create.

[heitorlessa]

Assigning to myself so I can read it fully tomorrow

[heitorlessa]

It sounds sensible to me, thanks for pulling this together as a user story format! I have three immediate concerns:

1. This may not be precise due to clock differences so messaging must set the right expectations.
   • [Suggestion] Any maintainer can help with that.
2. Depending on how the data is in the schema, we need to be careful with the algorithm to avoid a performance bottleneck (type conversion * N condition). Be prepared for potential compromises.
   • [Suggestion] Load testing would be a requirement to understand the impact on more realistic use cases.
3. I'd love to see some UX examples before going full blown on the implementation.
   • [Suggestion] Start with a fork, and let's keep this issue going before a PR. We need to get V2 out of the door ASAP, so I'd like to avoid increasing context switching on maintainers leading to sub-optimal UX here and V2 launch.

[ran-isenberg]

@heitorlessa take a look at this branch:
992371f

I think the UX is nice. Note that you dont need to supply any key to the context.
I think we can optimize the current date/time calculation at the start of the evaluate if we know we have date conditions and also store the string based full date into unix time int.

WDYT?

[ran-isenberg]

btw, if we used pydantic to store & parse the conf, this feature could have even simpler :)
maybe sometime in the future ;)