Getter for DateTime or any type for Metadata

[apatenge]

Hi OpenFeature .NET team,

to use metadata to provide for example an expiry date for the flag could be a common use case.
Therefore it would be great to add an getter for DateTime data type to the FlagMetadata class.
Alternative the GetValue method could be made public to get any data type easily.
Maybe both way would be also an option.

I have changed and tested successfully the following locally on my system based on lib v1.6.0:

In BaseMetadata.cs
I have added:

/// <summary>
/// Gets the DateTime value associated with the specified key.
/// </summary>
/// <param name="key">The key of the value to retrieve.</param>
/// <returns>The DateTime value associated with the key, or null if the key is not found.</returns>
public virtual DateTime? GetDateTime(string key)
{
return this.GetValue<DateTime>(key);
}

And I have changed:

private T? GetValue<T>(string key) where T : struct

to

public T? GetValue<T>(string key) where T : struct

In order to use an official release of open feature lib I am currently using an uncomfortable workaround in my provider, where I am replacing all DateTime objects in metadata by strings before I return it to the feature client. Then I can get it as string. A direct access to the date time would be much cleaner and convenient.

I hope this is a helpful change. I am looking forward to find this in one of the next release (maybe already in v1.6.1 ;)

Many thanks.

Regards,
André

[beeme1mr]

Hey @apatenge, the spec currently defines that flag metadata values can be type boolean, string, or number. That's not a deal breaker here but it would require a minor update to the spec.

FYI @open-feature/technical-steering-committee

[apatenge]

Hello @beeme1mr, understand, then I will ask the open feature committee for that spec change. Thanks.

[thomaspoignant]

Could it be just a sugar notation on top of string that is doing the parsing?

[apatenge]

I am not sure if I completely understand. To use the string is not a problem. It can for sure be parsed into a DateTime.

I can see there two problems:

First is when someone sends a DateTime in the metadata which is possible because it is a "string to object dictionary" in the background, then he would expect to be able to that DateTime back from metadata.

The second is, when would turn the DateTime into a string before putting it into the metadata and send it along JSON the JSON parser turns it into a DateTime at deserialization. I guess there is also a way to prevent from this. But it happend to me.

For now I am fine with my solution.

It is more a question of convenience for the future.

Thanks.