-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
JRuby 9.0.5.0: %Z behavior is incompatible between strptime and strftime #3702
Comments
In this case, it's not a matter of strftime. Because the receiver, created by strptime, doesn't have timezone name. So this is an issue of strptime, "How should strptime handle %Z?". The string is system/local dependent. For example Ruby on Windows, it is "Pacific Standard Time" or "日本標準時". Maybe it can be used for display, it can't be used for timezone information. glibc says simple answer for this. People must get the offset with "%z". |
@nurse do you mean that applications shouldn't use starptime with %Z? Then, Expected Behavior "a)" sounds the right approach because actual behavior doesn't matter. |
Guessed value should always be %z. See jruby/jruby#3702 for the discussion.
Yeah, application shouldn't use %Z. They must get time offset or IANA timezone name, which can get from %z or ... something else. I don't have any opinion about JRuby's strptime(%Z). |
Should this issue be closed since #3758 was merged in? |
was fixed for 9.1.0.0 to match up with MRI |
And its behavior is different from CRuby.
Environment
On Mac OS X, using System Preference.app, I set system timezone to JST (+0900).
Actual Behavior
JRuby 9.0.5.0:
JRuby's
strftime
with%Z
outputsUTC+7
, andstrptime
doesn't understand it (with neither%z
or%Z
).CRuby 2.3.0:
CRuby's
(one space), and of course,
strftime
with%Z
outputsstrptime
doesn't understand it.Expected Behavior
strptime
can parseUTC+7
using%Z%
(and improve CRuby as well), orstrftime
outputsPDT
or+0700
using%Z%
(and improve CRuby as well)Although it's behavior is different from CRuby, JRuby 9.0.5.0's improvement is good, I think. So, I prefer b) or c).
The text was updated successfully, but these errors were encountered: