search

open-feature / spec

OpenFeature specification
https://openfeature.dev
Apache License 2.0
597 stars 35 forks source link

chore: clarify timezone requirement #150

Closed toddbaert closed 1 year ago

toddbaert commented 1 year ago

A small change to make the timezone info on the Datetime type optional. Some SDKs already do not include timezone info.

Since it's loosening this definition, this is non-breaking.

agentgonzo commented 1 year ago

Which SDKs don't support timezones (and can they be taken out the back and shot?) ? Is it that they "don't" (and can thus be fixed to include them) or "can't" by virtue of the language.

I struggle to believe that they can't.

Ambiguous times are a terrible terrible thing to put in at the design stage. At the very least, the spec should explicitly state that if the timezone is not present, it WILL be treated at UTC but I would prefer to exhaust all other options before making timezone optional (unless it is something that is by definition zoneless like UNIX time).

toddbaert commented 1 year ago

Which SDKs don't support timezones (and can they be taken out the back and shot?) ? Is it that they "don't" (and can thus be fixed to include them) or "can't" by virtue of the language.

I struggle to believe that they can't.

Ambiguous times are a terrible terrible thing to put in at the design stage. At the very least, the spec should explicitly state that if the timezone is not present, it WILL be treated at UTC but I would prefer to exhaust all other options before making timezone optional (unless it is something that is by definition zoneless like UNIX time).

Maybe this is a phrasing issue. I was basically trying to address a possible misintrpetation of the previous requirement, namely: "you must set a tz/locale". I'm trying to refer to this change: https://github.com/open-feature/java-sdk/issues/59

To your point in the PR above, timezone-less entities are better - it's optimal to make times "delocalized" but absolute, like Instant or unix-times; that's indeed what I'm trying to encourage. Maybe the original phrasing is better, and we can recommend a timestamp with an implicit or explicit UTC tz?

agentgonzo commented 1 year ago

OK, it sounds like it's a phrasing issue and I'm overthinking it. As long as the interpretation is "no timezone => UTC" then all is good.