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? >>>>> "MS" == Michal Suchanek <hramrach / centrum.cz> writes: MS> yes, the problem is that you have to deal with strings also outside of MS> view, and you want to do that independently of the view and its MS> locales. >> >> That's what I like and appriate with academical people: >> they are not pragmatic, and they don't need to be ;-) >> And it's good that way. Serious. >> >> Dear Michal, you are right in that it should be dealt with software with >> multiple user interfaces, >> all dealing with users in entirely different locales. MS> No, I meant software dealing with texts in different languages. MS> Different languages have different sorting rules (even for the same MS> letters) but you have only one locale. MS> That's why I don't really like the idea of using locale too much. That's fine, but I do want to use it, and it comes for free in any UNIX / Linux / Mac / Cygwin (/ Windows?!?) environment so why not simply pass it through w/o confusing the interpreter's runtime system and enjoy it. I mean: re-implementing it in ruby, just because it's nicer (+ slower) in ruby, is ... >> > no, it's avoiding it. The locale was set to "C" in 1.8, >> > and now only LC_CTYPE is set. >> >> Oh, and that's not set *to* *a* *value*? >> >> Matz wrote, that this is done: >> >> setlocale(LC_CTYPE, ""); MS> Yes, it's correct. It means "set locale from the environment variable" So why does my example not work with my ruby1.9, just downloaded and built yesterday? $ env LC_ALL=fr_FR /usr/local/ruby1.9/bin/ruby \ -e 't = Time.now; puts t.strftime("%A")' Friday $ env LC_ALL=fr_FR date '+%A' vendredi MS> With ruby 1.9 you get exactly that. I would love to see that, but it seems to be incorrect. MS> Yes, this is ruby's strftime that operates on ruby Time values and has MS> nothing in common with the libc strftime except the name ;-) It 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. MS> You cannot just pass them. MS> It's not too hard MS> to convert limited subset of possible ruby valus MS> to C values and use the C localized functions on them. MS> 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. MS> and certainly not all Bignums. Alright. MS> I am not very fond of localized date/time formats. MS> I find them confusing. MS> Anybody and anything should be able to parse 2008-01-18, MS> 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. MS> Still it should not be too hard to use the C strftime MS> if anybody wants to do so. MS> 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? Kind regards, J. -- http://Hayek.name/Jochen http://www.LinkedIn.com/in/JochenHayek