-
Notifications
You must be signed in to change notification settings - Fork 664
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
Surprising %c
behavior
#704
Comments
Interesting. On my machine (macOS) I don't get the CET (or any other abbreviation besides the EST at the end). My best guess is that the combination of the en_GB.UTF-8, and the use of %c is producing the CET. When parsing the format string, this library forwards %c to the stream using the |
I've tried a couple other locales (nl_NL.UTF-8, en_US.UTF-8) and I keep getting
Thanks for the suggestion, I might just do that! |
Actually this wouldn't work -
If this is not isolated to my machine I'll probably disable the flag for now. |
Thanks for the reply and input! :) |
Everything documented as locale dependent, is implemented by forwarding the request to The one exception to the above rule is that if you compile with the macro |
Oh got it. That is good to know. |
Thanks for the great library @HowardHinnant !
I'm adding some functionality to Apache Arrow's
strftime
and I came across this behavior:Prints:
So
%Z
flag returnsEST
as I expect but%c
returnsCET
as the timezone. Probably because my system is set toCET
but is that the expected behavior?My machine runs Ubuntu 21.04,
LC_TIME=nl_NL.UTF-8
andcat /etc/timezone
returnsEurope/Amsterdam
but I also noticed this happened on Arrow's CI.The text was updated successfully, but these errors were encountered: