Hi, Michal,
you definitely are a hard-core newsgroup/ml guy, aren't you?!
Me, too.But: just not to forget the (more or less explicit) subject of this thread,
it refers to the "POSIX locale concept" and the ruby (non-)compliance with it.And we got carried away from it, didn't we?
We got into discussion about the pitfalls of combining an object
oriented language like Ruby with a process oriented interface like
POSIX locale. The strftime function itself des not allow specifying
the locale so you can only set the locale globally which is very
unpleasant behavior.
It is true that in most cases you only need a single locale. However,
the locale of each Time instance should be independent of any other
Time instance to allow for situations when data in multiple languages
exist in a single program.
If that was not possible we would only get from one misleading
situation into another. You woula have a Time object that can change
behavior suddenly.
[...]
> Yes, this is ruby's strftime that operates on ruby Time values and has
> nothing in common with the libc strftime except the nameIt does have in common most of it,
so not complying 99.5 % is what I call "camouflage" and simply misleading the programmer user.
I assume, you will agree here.
The ruby strftime is a method of Time that implements part of
well-known strftime interface ot top of Time values. It may be
misleading not to implement all aspects but the localization simply is
not there, and would require quite a bit of work to add.
> You cannot just pass them.
> It's not too hard
> to convert limited subset of possible ruby valus
> to C values and use the C localized functions on them.> But you probably cannot format all Time values,
Probably, so let's assume returning strings on the ruby heap or stack *would* actually *work*.
You know my roots are in the compiler and interpreter business of the 80-s.
I implemented a code generator and a runtime system for Ada on a Motorola 68k on a bare machine and also within a SysV UNIX,
I helped the Modula2 compiler guys from next door,
in implementing a first I/O library based on the C printf/scanf utilities,
I made use of the Tcl-C interface,
...,
so I can dare to say,
that things in that area are not overly complex
and with a quality approach it can even be achieved w/o creating memory leaks and "almost" bugfree.
Regular business.> and certainly not all Bignums.
Alright.
> I am not very fond of localized date/time formats.
> I find them confusing.
> Anybody and anything should be able to parse 2008-01-18,
> and it even sorts correctly in dictionary order.I fully agree to you.
I started using this ISO date format next to my signature on forms back in the early eighties.
And I learned esperanto then.But in real life people want to speak French, Czech, German, Portugues, Spanish, Russian, and also English,
and they want to use their familiar date format.
I want to use only date formats I can interpret. Many of the shortened
localized date formats using numbers are hard to interpret, including
some Czech ones.
> Still it should not be too hard to use the C strftime
> if anybody wants to do so.> You are welcome to update the ruby-locale extension if you are so concerned
I feel, like my enhancements would also not find their way into the released source,
just like the patch stemming from 2002.And how can I recommend using such a crappy enhancement to people in my local user group?
It might not have found its way into the source because people did not
find it that important at that time or because ruby was not ready to
accept locale at that time.
Either way since you are backed with such tremendous experience you
can dust off the extension and check that it works properly. Noone
could say it's just a crappy abandoned piece of code then 
Thanks
Michal
···
On 18/01/2008, Jochen+nntp-20071217@hayek.name <Jochen+nntp-20071217@hayek.name> wrote: