hello all

i've noticed that DateToStr gives correct results on win32 (regarding locale), but on linux and osx it always gives the date as dd-mm-yyyy. i read somewhere in the archives that there's a problem implementing this due to the need to link to libc or something (hand wavy). can anyone shed some light on this for me, or does anyone know about a work around?

thanks
henry

The locale info on Linux is stored in some files somewhere in /usr/lib/* The routines to access these files are in Libc. Since SysUtils should remain free from dependencies on the C library, we cannot use it to initialize the constants...

I have somewhere a unit that links to C or uses the KDE info to initialize the localization constants in SysUtils. If you don't mind linking to C then I can send you this.

If you want to make a Pascal version of the localization routines, then
Please do :-)

Michael.

o.k. i've had a look at the libc source (locale dir). i understand the general gist of things, but it'd take ages to implement in pascal if i try and transliterate that. it's also not very easy to read (due to a generous use of defines). what work has been done on this for fpc? is there any (more readable) documentation on the locale binary files? posix docs?

to get the time and date format info i'd have to do this:

(1) get the locale that's being used (LANG environment variable). mine gives en_GB.utf8
(2) open the LC_TIME file that can be found under
/usr/lib/locale/{locale from (1)}/
(3) extract the date and time format from this file

sorry it's not more specific, but that's the main idea. it would obviously make sense to implement the whole lot of locale functions. i think it's quite fundamental. will fpc choose to mimic what libc does? it'd quite nice to have a single function that queries certain variables from certain categories (e.g. LC_MONETARY, LC_TIME, LC_NUMERIC).

i'll see if i can do some more work on this.

thanks
henry

Yes, this is the idea.

sorry it's not more specific, but that's the main idea. it would obviously make sense to implement the whole lot of locale functions.

Indeed. I would expect you to open the correct file, and initialize all variables from that file.

i think it's quite fundamental. will fpc choose to mimic what libc does?

If you mean read the files and initialize the necessary variables, the answer is yes.

it'd quite nice to have a single function that queries certain variables from certain categories (e.g. LC_MONETARY, LC_TIME, LC_NUMERIC).

That can be done too, but since all constants are in 1 file, it makes more sense to process the .

Not portable. E.g. on BSD it is /usr/share/locale
So between 1 and 2 there should be a step "find locale dir".

This because a solution is required to be Solaris, BSD and Mac OS X compatible.

Another solution would be to have an additional unit that links to libc and gets the data. This way the limiting libc linking would only happen at the writers request, and not hamper all sysutils using programs.

marco said:

true, there is a findlocale.c file under libc that deals with this. this is a necessary step.

> it'd quite nice to have a single function that queries certain > variables from certain categories (e.g. LC_MONETARY, LC_TIME, > LC_NUMERIC).

michael said:

That can be done too, but since all constants are in 1 file, it makes more sense to process the is a separate file for each category, it seems.

i'll try and investigate further and look for the posix docs. thanks for the comments.

henry