Asp Forum - dow ruby's strftime not attempt POSIX-compliance?

Jochen Hayek

1/8/2008 9:57:00 PM

Why is ruby's core class Time acting like this:

$ env LC_ALL=fr_FR date '+%A'
mardi
$ env LC_ALL=fr_FR ruby -e 't = Time.now; puts t.strftime("%A")'
Tuesday

I would actually like ruby to act like "date" and "obey"
to POSIX or whatever we are used to in the *IX world,
which in turn certainly uses libc's strftime.

I heard rumour, that "this is the standard",
and "it must stay this way".

Would somebody pls shed some light on this?

J.
--
Posted via http://www.ruby-....

7 Answers

Suraj Kurapati

1/8/2008 10:22:00 PM

Jochen Hayek wrote:
> Why is ruby's core class Time acting like this:
>
> $ env LC_ALL=fr_FR date '+%A'
> mardi
> $ env LC_ALL=fr_FR ruby -e 't = Time.now; puts t.strftime("%A")'
> Tuesday
>
> I would actually like ruby to act like "date" and "obey"
> to POSIX or whatever we are used to in the *IX world,
> which in turn certainly uses libc's strftime.

In Ruby 1.8.x, you need to use the external ruby-locale library to set
the locale before you use any Date/Time functions (otherwise the output
is always in English). See this post for an example:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

> I heard rumour, that "this is the standard",
> and "it must stay this way".

It has been the "standard way" for 1.8.x, but I hope 1.9 fixes this.
Does anyone know?
--
Posted via http://www.ruby-....

Suraj Kurapati

1/8/2008 10:22:00 PM

Suraj Kurapati wrote:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

Correction:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...57474
--
Posted via http://www.ruby-....

Jochen Hayek

1/9/2008 12:10:00 AM

Suraj Kurapati wrote:
> See this post for an example:
> [...]
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-...

Given Matz's note,
so how would the 2002 ruby-talk translate into ruby1.9?
And I mean "using LC_ALL".

J.

P.S.
How did I manage to write "dow" instead of "does"?
--
Posted via http://www.ruby-....

Suraj Kurapati

1/12/2008 3:29:00 AM

Jochen Hayek wrote:
> Suraj Kurapati wrote:
>> See this post for an example:
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-...
>
> Given Matz's note,
> so how would the 2002 ruby-talk translate into ruby1.9?
> And I mean "using LC_ALL".

You don't really need LC_ALL if you only want to translate date & time.
Here are some examples using LC_TIME:

$ irb -r locale # assuming you installed ruby-locale for Ruby 1.8
>> Time.now
=> Tue Oct 23 13:12:20 -0700 2007

# in German:
>> Locale.setlocale(Locale::LC_TIME, "de_DE"); Time.now
=> Di Okt 23 13:12:32 -0700 2007

# in Spanish:
>> Locale.setlocale(Locale::LC_TIME, "es_ES"); Time.now
=> mar oct 23 13:15:19 -0700 2007

# in Italian:
>> Locale.setlocale(Locale::LC_TIME, "it_IT"); Time.now
=> mar ott 23 13:15:27 -0700 2007
--
Posted via http://www.ruby-....

Jochen Hayek

1/12/2008 10:20:00 PM

Pls let me assure you in the beginning of this note,
that it's not my intent to start any flame war
and also that I do not want to offend anybody honorable.
It's only about reasonable employment of good willing programmers'
resources
and constructive use of pre-existing software and standards
like glibc, POSIX, ...

>> Suraj Kurapati wrote:
>>> See this post for an example:
>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-...

The article referred to here talks about an interpreter patch dated
around 2002,
that did not make its way into "MRI" by now,
de facto it's not part of 1.8.6,
neither is it part of 1.9,
let's call it dead therefore.
I would love to learn, that I am not right there,
but I do fear, I am.

If I understood Matz correctly,
then "1.9 calls setlocale() ... for LC_TYPE" *internally*
and obviously setting any of the LC_* environment variables
of a ruby script has *no* *effect* *whatsover*.

Apparently these env. variables get overwritten within the interpreter,
let's consider this locale setting as "*frozen*",
and is my assumption correct,
that various rather "central" software makes uses of this *frozen*
locale,
I mean e.g. all the library code,
that handles HTTP protocol date/time strings.

Therefore that "central" code would break,
if the interpreter and its "kernel library code"
would get the *frozen* locale setting removed.

Is that correct?

But wouldn't it still be a good idea,
to give the world, what (g)libc actually already implements,
I mean all the features directed by those LC_* env. variables,
e.g. language/region dependant date/time strings, currency,
thousands/decimal separators, etc. pp.?!!!!

I mean it shouldn't be that hard
to cure the code, that depends in turn on that frozen locale setting,
and furtheron to remove this freezing, right?

Instead programmers interested in doing I18N / M17N capable ruby
and therefore particularly also rails code
all around the world have to desperately seek ways to implement I18N /
M17N.

That sounds like a tremendous waste of resources
because of a maybe unlucky decision regarding the frozen locale setting.

J.
--
Posted via http://www.ruby-....

Suraj Kurapati

1/12/2008 10:58:00 PM

Jochen Hayek wrote:
> Pls let me assure you in the beginning of this note, that it's
> not my intent to start any flame war and also that I do not want
> to offend anybody honorable.

Ah, don't worry about it. In general, the audience here on ruby-talk
is quite open-minded and respectful -- or so I would like to think. :-)

> It's only about reasonable employment of good willing
> programmers' resources and constructive use of pre-existing
> software and standards like glibc, POSIX, ...

Good, you are correct to be concerned!

>>> Suraj Kurapati wrote:
>>>> See this post for an example:
>>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-...
>
> The article referred to here talks about an interpreter patch
> dated around 2002, that did not make its way into "MRI" by now,
> de facto it's not part of 1.8.6, neither is it part of 1.9, let's
> call it dead therefore. I would love to learn, that I am not
> right there, but I do fear, I am.
>
> If I understood Matz correctly, then "1.9 calls setlocale() ...
> for LC_TYPE" *internally* and obviously setting any of the LC_*
> environment variables of a ruby script has *no* *effect*
> *whatsover*.

Hmm, I thought Matz said that Ruby 1.9 does this:

setlocale( ENV['LC_TYPE'] )

instead of this:

setlocale( 'C' )

Matz, would you please clarify?

> Apparently these env. variables get overwritten within the
> interpreter, let's consider this locale setting as "*frozen*", and
> is my assumption correct, that various rather "central" software makes
> uses of this *frozen* locale, I mean e.g. all the library code,
> that handles HTTP protocol date/time strings.

Correct. A Ruby 1.8 script can only change the locale using the
ruby-locale library.

> Therefore that "central" code would break, if the interpreter and
> its "kernel library code" would get the *frozen* locale setting
> removed.

Good point. I never realized this!

> But wouldn't it still be a good idea, to give the world, what
> (g)libc actually already implements, I mean all the features
> directed by those LC_* env. variables, e.g. language/region
> dependant date/time strings, currency, thousands/decimal
> separators, etc. pp.?!!!!

Agreed.

> I mean it shouldn't be that hard to cure the code, that depends
> in turn on that frozen locale setting, and further on to remove
> this freezing, right?

Ah, you are hinting at a setlocale() method that accepts a block:

# assuming that Ruby has a Kernel#__set_locale__ method
class Kernel
def set_locale *args
if block_given?
old = locale

begin
__set_locale__ *args
yield
ensure
__set_locale__ old
end
else
__set_locale__ *args
end
end
end

# using C locale out here

set_locale( LC_TIME, 'de_DE' ) do
# do stuff with German locale
end

# using C locale out here (again)

> Instead programmers interested in doing I18N / M17N capable ruby
> and therefore particularly also rails code all around the world
> have to desperately seek ways to implement I18N / M17N.
>
> That sounds like a tremendous waste of resources because of a
> maybe unlucky decision regarding the frozen locale setting.

Yes, that would be a quite unfortunate case. But let's wait for
Matz to clarify this situation so we can be sure of the problem.
--
Posted via http://www.ruby-....

Michal Suchanek

1/14/2008 12:47:00 PM

On 12/01/2008, Suraj Kurapati <snk@gna.org> wrote:
> Jochen Hayek wrote:
> > Pls let me assure you in the beginning of this note, that it's
> > not my intent to start any flame war and also that I do not want
> > to offend anybody honorable.
>
> Ah, don't worry about it. In general, the audience here on ruby-talk
> is quite open-minded and respectful -- or so I would like to think. :-)
>
> > It's only about reasonable employment of good willing
> > programmers' resources and constructive use of pre-existing
> > software and standards like glibc, POSIX, ...
>
> Good, you are correct to be concerned!
>
> >>> Suraj Kurapati wrote:
> >>>> See this post for an example:
> >>>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-...
> >
> > The article referred to here talks about an interpreter patch
> > dated around 2002, that did not make its way into "MRI" by now,
> > de facto it's not part of 1.8.6, neither is it part of 1.9, let's
> > call it dead therefore. I would love to learn, that I am not
> > right there, but I do fear, I am.
> >
> > If I understood Matz correctly, then "1.9 calls setlocale() ...
> > for LC_TYPE" *internally* and obviously setting any of the LC_*
> > environment variables of a ruby script has *no* *effect*
> > *whatsover*.
>
> Hmm, I thought Matz said that Ruby 1.9 does this:
>
> setlocale( ENV['LC_TYPE'] )
>
> instead of this:
>
> setlocale( 'C' )
>
> Matz, would you please clarify?
>
> > Apparently these env. variables get overwritten within the
> > interpreter, let's consider this locale setting as "*frozen*", and
> > is my assumption correct, that various rather "central" software makes
> > uses of this *frozen* locale, I mean e.g. all the library code,
> > that handles HTTP protocol date/time strings.
>
> Correct. A Ruby 1.8 script can only change the locale using the
> ruby-locale library.
>
> > Therefore that "central" code would break, if the interpreter and
> > its "kernel library code" would get the *frozen* locale setting
> > removed.
>
> Good point. I never realized this!
>
> > But wouldn't it still be a good idea, to give the world, what
> > (g)libc actually already implements, I mean all the features
> > directed by those LC_* env. variables, e.g. language/region
> > dependant date/time strings, currency, thousands/decimal
> > separators, etc. pp.?!!!!
>
> Agreed.
>
> > I mean it shouldn't be that hard to cure the code, that depends
> > in turn on that frozen locale setting, and further on to remove
> > this freezing, right?
>
> Ah, you are hinting at a setlocale() method that accepts a block:
>
> # assuming that Ruby has a Kernel#__set_locale__ method
> class Kernel
> def set_locale *args
> if block_given?
> old = locale
>
> begin
> __set_locale__ *args
> yield
> ensure
> __set_locale__ old
> end
> else
> __set_locale__ *args
> end
> end
> end
>
> # using C locale out here
>
> set_locale( LC_TIME, 'de_DE' ) do
> # do stuff with German locale
> end
>
> # using C locale out here (again)
>

As far as I know locale is set for the process, not for thread. Since
ruby is multithreaded this method of dealing with locale would be very
unsafe. Some libc functions that use locale use the one that was set
up by setlocale, some can even use one provided in a special argument.

Either way ruby should not use them for its core functionality, and
even cannot as its basic data types are mostly different from the C
basic data types. However, you could extend the ruby-locale library to
provide bindings to some of the more useful libc functions that depend
on locale (if it does not yet).

Thanks

Michal

comp.lang.ruby

dow ruby's strftime not attempt POSIX-compliance?

Jochen Hayek

Suraj Kurapati

Suraj Kurapati

Jochen Hayek

Suraj Kurapati

Jochen Hayek

Suraj Kurapati

Michal Suchanek

x Login to ForumsZone