Flagsmith
Epic: Allow date comparisons in segment rules
Is your feature request related to a problem? Please describe.
I would like to be able to do date comparisons on a trait in a way that is easy for non-technical users to configure.
Describe the solution you'd like.
New rule operators that allow for date comparison, e.g. some_trait [before | on | after] YYYY-MM-DD, where some_trait could be an ISO-formatted date string, epoch time, or some other format (doesn't really matter). In terms of impl, would probably just be a wrapper around numeric comparison with epoch time.
Describe alternatives you've considered
This is currently possible with numeric comparison if we use epoch time on both sides. However, it would be a nice QOL feature (especially for non-technical users) if we didn't have to do the conversion or think about epoch time at all.
Additional context
No response
Hi @utkarsh-1905 , this is quite a large amount of work as it will need to be implemented in the engine code in all of our server side SDKs. If you're willing to take all of that on, then great, yes!
In terms of the design for this, I think we will need some new operators to ensure that the engine knows when to correctly format the value as a date. When these operators are chosen in the UI, it should provide a date picker to select from.
Yes, I am willing to take this up, in turn this will help me to understand the codebase better, so I can contribute more in the future, though I will ask a lot of doubts here 😅
We need to give consideration here to timezones too?
Hmm... yes, I guess we either need the dates to always be TZ aware or always NOT TZ aware (and hence we assume UTC). We perhaps needs to do some research into what other feature flagging / analytics tools are doing in this regard to get some inspiration. @utkarsh-1905 could you take a look?
@tomerplus500 at the moment, we don't have a timeline for implementing this one. In the meantime, you can use integer timestamps. e.g. set your trait as follows:
flagsmith.get_identity_flags("my-identity", traits={"registered_at": int(datetime.now().timestamp())}
Then you can use the standard inequality operators in your Flagsmith segments as if the value is numeric.
@tomerplus500 at the moment, we don't have a timeline for implementing this one. In the meantime, you can use integer timestamps. e.g. set your trait as follows:
flagsmith.get_identity_flags("my-identity", traits={"registered_at": int(datetime.now().timestamp())} Then you can use the standard inequality operators in your Flagsmith segments as if the value is numeric.
While we can do this, it will be hard to hand craft rules in the Segment Override UI. Need to convert specific date/time format to number, also, very unreadable when you try to understand when the rule should applied - need to convert back aside, each time.
Could you please add date/time selector/annotation in the UI, so we can set/read human format date/time?
@tomerplus500 yes, this is something that we do plan to implement, but as per previous comments, it is a non-trivial requirement and is not on our near term backlog, hence my suggestion for a workaround for the time being.
@tomerplus500 yes, this is something that we do plan to implement, but as per previous comments, it is a non-trivial requirement and is not on our near term backlog, hence my suggestion for a workaround for the time being.
Why adding "date util" to the UI only is a non-trivial requirement? This change is in the UI only. The UI will convert the date time to interval. SDK stays the same.
We'd happily receive a PR for this :)
React is not my cup of tea .. :)
Contrary to the discussion here, I believe we should benefit from adding proper datetime support to the engine.
Adding support to the engine alone won't move a dime.
I did that by customizing the Engine in .NET - problem is that the UI doesn't support trait such as: RegistrationTime > 2025-04-12.
This is ridicules and I really don't understand how such an important requirement don't get super high priority.
The least you can do is support: 2025-04-12, 2025-04-12 14:00 and 15:34 formats in the UI and don't block us from adding such value with >, >=, <, <= operators. This is not much to ask!
Hi @tomerplus500, I appreciate the feedback, but please bear in mind that we have a backlog to manage for both our open source community and paying customers. Since there is a valid workaround for this issue, and we don't have any other customers asking for it, I'm afraid that it is not a priority for us right now.
Please be nice :)
I appreciate that you have paying customers - I'm sure this one will satisfy them too. Also if you want to have more satisfied paying customers, this one is a must have. You see, as a developer or product manager, you don't expect someone to translate Human Readable Time to UNIX/Epoch time. Not that it's not readable and confusing looking at the Flagsmith UI, it's prone to errors and not maintainable. The least is to support the required format in the UI and not blocking it. I'll manage with the Engine side.