-
Notifications
You must be signed in to change notification settings - Fork 40
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
chore: clarify timezone requirement #150
Conversation
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: open-feature/java-sdk#59 To your point in the PR above, timezone-less entities are better - it's optimal to make times "delocalized" but absolute, like |
OK, it sounds like it's a phrasing issue and I'm overthinking it. |
Signed-off-by: Todd Baert <toddbaert@gmail.com>
Co-authored-by: Steve Arch <sarch@cloudbees.com> Signed-off-by: Todd Baert <toddbaert@gmail.com>
9ddde8d
to
c2fd188
Compare
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.